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(54) TiUe: INTERNET PAYMENT AND LOADING SYSTEM USING SMART CARD 
(57) Abstract 204^ 

An architecture and system 
loads and uses a smart card (5) for 
payment of goods and/or services 
purchased on-line over the Internet . 
(202). A client module "on a^llcht "~ 
temiinal (204) controls the inter- 
action widi a consumer ^suid inter- 
faces to a card reader (210) which 
accepts the consumer's smart card 
(5) and allows loading and debit- 
ing of the card. Debiting works in 
conjunction with a merchant server 
(208) and a payment server (206). 
Loading works in conjunction with 
a bank server (860) and a load 
server (862). The Internet provides 
the routing functionality between 
the client terminal and die various 
servers, A payment server (206) 
on the Internet includes a computer 
and a security module (or a secu- 
rity card (218) in a terminal (214)) 
to handle the transaction, data store ^ . v * 

and collection. A merchant server (208) advertises the goods and/or services offered by a merchant for sale on a web site. The mercnant 
contracts with an acquirer to accept smart card payihents for goods and/cnr services purchased over the Internet, A consumer uses his smart 
card (5) at the client terminal (204) in oder to purclwsc goods and/or swic«Jfrom-tiw rcrnpte servc_rX208). The client terminal 

sends a draw request to the payment server. The payrnent server processM, cpnfinns and relies to the merchant server (optionally by way 
of the client terminal). To load value, the cUcnt terminal (264yrequests aJ^frtMn a user account at the bank server (860). A load request 
is sint from tiic^ (5)'toWlbad i^Ues to the* bank server (optionally by way of the cUcnt 

t^rminal).:mie:l^hk^ ^P^^ purchase good^ 

with Valuc.onjhexajd, 
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5 - The present invention relates^gene^ anS a value loading 

system using a computer netwprk:^More ;s{^ to a 

payment systern smd a yalue.lo^ding'sys^^ using ari^bpen network such as 
the Internet^- ■ 'ffe:^'P^ ■■ . / ' 

^ " BAckGROU>BoF-T^ ^ 

1 0 With the explosive growth in open networks (such as the Internet) over the past 

several years and the rapid inc^ease iri^the nu^^ to the World 

Wide Web, there has been a gr^t deal of interest in the 'development of electronic 
commerce on the Internet. Traditional financial transactions are being transformed. 

A variety ojF service providers have introduced payment schemes to support the 
1 5 purchase of goods or services on-line in a virtual, merchant environment. These approaches 
have used several models based on traditional payment methods existing in the face-to-face 
retail market, incluciing credit/debit cards; checl^ a^ for a variety of 

reasons^vMous of these nunierous schemes 

Currently, a consumer may use his or her traditional credit or debit card to make a 
20 purchase over the Internet. A consumer simply supplies his card account number which is 
then transmitted across the Inteme^^^^ merchant anci the payment transaction is completed 
in the traditional manner for a credit card.^ Often, these account numbers are transmitted 
over the Internet with extremely limited or no security. Security can be improved through 
use of the "Secure Electronic Transaction" protocol published by Visa International and 
25 Mastercard in 1996. These transactions still require some form of card validation and 
performance of a balance check. These checks are performed on-line between the 
merchant, an acquirer and an issuing bank, a process which can become time consuming 
and inefficient when the value of the transaction is low, or when a number of small value 
transactions will be taking place in a short time span. 

30 The electronic check is modeled on the paper check, but is initiated electronically 

using digital signature and public cryptography. Deposits are gathered by banks via 
electronic mail and cleared through existing channels such as the Automated Clearing 
House (ACH). However, iise of such ari electronic check bjT a consumer has. various 





' ^ . drawbacks/ For one, lis^ ^ ^^^^^ 

authority adding additional entities and Vnerv trips ti^th^ cardholder . 




: ^ . S;4p^., Mis- 
registration IS needed, 
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Other Internet payment alternatives are modelaa bn^cash transactions and include s ; 



variety of schemes. With CyberGash^tfreBbhsi^^^ riumbeir tb'an -^- ; 

electronic invoice received from the merchantrrctums iRel^ cani number to. the^^^" ^ 



merchant which is Jdhen p 



then\treated . . 




A digital, token-based system for Internet transactions hiEis been imptemented by ' ; :M 
DigiCash. With DigiCash, so-called "digital coins" are purchased fr^ a 1^ ' 

prefunded deposit account and stored on the consumer's hard drive. These digital coins are ' 
then used for an Internet transaction with a merchant. This scheme has disadvantages in ; ■ - 
that the consumer must first set up a relationship with DigiCash and use a cr&dit card or :^ 5 
similar instrument to purchase these digital coins, which then must be downloaded to the 1 ^ 
consumer's computer. This transaction can be time consuming for the consumer,and is • ; v. 
subject to fraud. In addition, a merchant must be set up to not only accept the^ digital 
coins, but also to verify their authenticity, to confirm the transaction, and then Hnally to 
foTv/ard these numbers on to his bank in order to finally get paid. One drawback from the :^ 
merchant's point of view is that niuch of the transaction work inust be p^rfpnned by the i-^-^ 
merchant. - - - . ■ : 
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Another scheme for completing an Internet transaction is offered by First Virtual ' - * • . 
Holding,Inc. First Virtual offers a software solution based upon a unique identification 
number and electronic mail confirmation. To use this scheme, a consumer opens a special 
account with First Virtual and then receives a confidential identification number. When the 
consumer wishes to purchase a product or service over the Internet, he or she sends an : 
electronic mail message containing the confidential identification number to the merchant. 
The merchant then sends the number to First Virtual by electronic mail for verification and , 
identification of the customer. First Virtual then confirms with the consumer by electronic"^ 
mail that the consumer did indeed initiate the transaction and wishes to make the purchase. - 
There are drawbacks to this scheme in that the consumer must first open a special account^^ 
with First Virtual. ' Also, the merchant must communic^ 
customer and to identify the customer's credit card account number that'is identified Iw^ 
_ confidential identification number. ; ;i:^rv -S M-'^i^^^^^^^^^^i^^^^^^^^^^^^^^^ 





'"^^^^ """" 
: financial traiisaction at a stand-alone.terrninal uses a sniart card. A smart card is typically a . 
credit card-sized plastic canl that'includes a senriiconductor chip for holding the digital 
equivalent of cash pointing to an account or providing credits. When a 

card pf this kind is used to maie a purc^ equivalent of cash is transferred to 

themercharu*s ^"^asif a financial ihstitutiori; Stored-value cards are 

- replenish^ in value for each transaction and Jthrown away when 
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'■'^ f^Phys^lly^^^^ card often resembles a traditional "credit" card having one or : 
morc^emconductoFdevic^ attached to a moduie embedded in the card, providing contacts 
16 Oie^outsii^^^^^ worid/ : The card can interface with a pbiht^f-sale tenninal, an ATM, or a 
card iMdef integrate into a telephone, a computer,' a vending machine, or any other 
appliance. A m semiconductor device embedded in "processor" smart card 

allows the card to undertake a range of computational operations, protected storage, 
encryption arid decision making. Such a microcontroller typically includes a 
microprocessor, memory, and other functional hardware elements. Various types of cards 
are described in 'The Advanced Card Report: Smart Card Primer", Kenneth R. Ayer and 
Joseph F. Schuler, The Schuler Consultancy, 1993, which is hereby incorporated by 
reference. 

One example of a smart card implemented as a processor card is illustrated in FIG. 
I . Of course, a smart card may be implemented in many ways, and need not necessarily 
include a microprocessor or other features. The smart card may be programmed with 
various types of functionality, such as a store(lryalue application; credit/debit; loyalty 
programs, etc For the purpose of this disclosure, card 5 is programmed at least with a 
stored-value application, and will be referred to as "stored-value" card 5. 

Stored-value card 5 has an embedded microcontroller 10 that includes a 
microprocessor 12, random access memory (RAM) 14. read-only memory (ROM) 16, 
non-volatile memory 18, an encryption module 22, and a card reader interface 24. Other 
features of the microcontroller may be present but are not shown, such as a clock, a 
random number generator, interrupt control, control logic, a charge pump, power 
connections, and interface contacts that allow the card to communicate with the outside 
world. 

Microprocessor 12 is any suitable central processing unit for executing commands 
35 and controlling the device. RAM 14 serves as storage for calculated_results and as stack y 

memory ROM 16 stores the operating system, fixed data, standard routines, and Ipok up , 
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S^PCn[WSW08806^^| 

iaWeS/^biv^yolffilc to EPROM or EEpReiM)1^^^^K^^^^^^^^S 

information that must not be lost when the card is disconnected from a power source but^^$^?^w^^^^B?/^E^^ 
^ that must also be alterable to accommodate data specific to in&Vidual^^^^^^^^^^ 

possible over the card lifetime. This information nught include a card identification ^pk^r^ T^A^^i-^i^^^^ 
: nuniber, a personal identification number, authorization levels^cash^alaifc^ 
jita %rici>;ip^ 22 is an optional hardware m^ 

olfOTcryptior^ Card reSer interface 24 incfiid^^ 




'0^ 



10 interfaceV a reiiiote-cotijpled interface/or a variety of other inteifaS^.^Wil^^ 

interface, isignals from the microcontroller are routed to ahumSSrpf m .... 
biftside of tl^ which come in physical contact withluniS^^f^ 

^^.^^dgice^^c/.^^^^ : . . • :-. : ; -{:;^|^^^^^^^^^|S^^^ 

\ -One possible use of a stored-value card by a consumer is iiliistraied in HQ; 2.;^ FIG/; l-^^^ /.V 
1 5 2 illustrates a block diagram of a customer operated service payment terminal 50;- A v. ^ . - ; . 

customer typically uses such a service payment terminal in a face-to-face ienvirohnient in ^ 
order to purth^e goods in a store or direcUy from the terminal itself iService payment ' ' 
terminal 50 can be an attended device or it can be integrated into a self-service device such 
as a vending machine or public telephone. For example, the service payment terminal may . ^ . : . 
20 be incorporated into a soda machine in order to dispense sodas to a customer in which the J . . , 
customer pays by inserting the stored-value card. Or, the service payment terminal may be . , . U . ; 
a point-of-sale terminal such as is found at a check-out counter where a customer inserts his 
stored-yalue card in order to purchase goods. J - > : > 

^™Servi?e"payment teniiinal 5^^^ 

25 hartdlS/reader54, a security card handler 56, a security card 58, a terminal application 60, . 
a data store 64 and a concentration point handler 66. Router 5 1 is hardware and software 
for routing information between functional blocks. User interface 52 controls the status of 
displays on the terminal and supplies instructions to the user. For example, the user . ; 
interface provides instmctions relating to insertion of stored-value card 5 or security card 

30 58. Also, the user interface provides instructions and/or buttons for the customer to 
interact with terminal application 60 in order to purchase goods and/or.seryices. Card 
handler 54 provides a physical card reader and associated software for accepting and 
communicating with stored-value card 5. Similarly, security card handler 56 provides a . . 
card reader and associated software for communicating with security card 58. In 

35 conjunction with security card handler 56, security card 58 controls the command sequence ' . 
of the terminal and provides transaction and a batch security; " -v^i^- — 
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Terminal applicati6n'66 i^iv^'^^^ the transaction 

and initiates the actual Purchase.: W Responsible for all 
=: application specific functionality^s^^ ofjie 
terminal via a display -'mdV^^ providfa|Wh^§^ to provide the 

,5 v-user with a good aiid^r sindc^bn^^fe^ . ^ 

appropriate value has t^n dedubt^fio^^ ' " 

Data store 64 controls the^^s^^^ 
ConcentradonTOinthan^^^^ : 

from a concentrator .PO^^J§?n^|^fg,^|J§^||||i^^ ^ : ^ 

10 communicates wi^'^nynumte^^^ 

transactions. They|cMt«d 

administration systeiii for proc^ssingls^h^^^ 

acknowledgmentsrfilcfiig withd 

concemration point. The conce^^^ 
1 5 service payment terminals and the cleaning and and prevents 

overloading of the clearing and administration system. The service provider contracts with 

a concentration point for collection of the service payments. The concena^^ 

also be an existing central facility such as a telephone company that collects its own 

payments froni card telephones, — v. .. ; . 

20 Such a service payment terminal 50 allows a customer to use a stored-value card for 

the payment of goods and/or services, generates a payment result from a transaction, and 
bundles indiyid^ual payment results into a collection for transfer to a clearing and 
administration system, which then transfere j^n^^ that had been debited from a customer's 
" stori^^a^e card to^t^ had been purchased from 

25 " thie'tOTnirial/'" ;^V^ _..7 / 

FIG. 3 illustrates an environment 100 useful for issuing stored-value cards and 
reconciling transactions performed with such a card. A terminal supplier 102 builds the 
equipment used by a service provider 104 to provide goods and/or services to customers 
having a stored-value card at a service payment terminal 50. Card Supplier 106 contracts 

30 with an integrated circuit manufacturer and a card manufacturer for integrated circuits and 
plastic card bodied, then embeds the integrated circuits into the cards and initializes them 
with a serial number. It then delivers the cards to card issuer 108. In conjunction with 
clearing and administration system' 1 10 (such as a system provided by Visa International of 
Foster City, CA), card issuer 108 personalizes new cards and then transfers these cards to 

35: individuals (cardhoWer^^^^^^ 

use. Alternatively; the ca^^^ come with value already loaded. The cardholder 1 12 may 

- . : then use the^^^^ purchase goods and/or servic^^from 



service payment : 

Periodically, all transactions are sent in a data file from terminal 50 via concentration 
point 68 aiid ah acquirer 1 1 4^tb clearing'and batch^administrafi I 
accumulated service payment batches from other tenninais,-"Based upon this collection 1 

^^aSrcl^aring and admin istratidh system 1 10 then reDbivesTr^^^^ issuer 108 - - ^r^ 

.which had originally come from cardhoidcr .1 12. Cleaffig , 
then transfers a lump sum to acquirer 1 14 using a suitable settle^ (such a^ one : 

provided by Visa International) to pay the various service piwid / 

, with acquirer 1 14. Based upon the previous collection data, acqiiirer n transfers an 
appropriate amount of money to each service provider'104 reflecting the yalue of the goods - 
and/or seryices that that service provider had provided that day cardholders based upon 
deductions froni th'dr stored- value ca^^ - r-: . 

Although such a service payment terminal described above is useful for the on-site 
purchase of goods by a consumer with a smart card, it does not permit the purchase of 
goods and/or services by a customer over a network. Nor does such a terminal permit the 
immediate transfer of electronic information to a consumer's coiriputerV Service payment 
terminals are typically specially-designed unite of hardw 

merchant site.; Furthermore, the service payment tcnrninal is d^^^ one 
hardware location the functions of the terminal ^plication (providing goods and/or 
services), a card handler for the storcd-value card,- and the transaction management 
embodied in the security card/ Such a design is not suitable for u^nsE^ctions where a^ 
customer may wish to perform a transaciiOT 

or Sfice^quickly' arid easily ^w^^ and expense; ' " ^ 

FurSermqrc, a^^ various Intemet^iiayment s^^^^ they are not 

oriented toward small value transactions, and do not allow the use of a smart card for 
transactions over the Internet. ' /-.y-. ----' 

Thus, it would be.desirable to have an architecture and system that would allow a 
consumer to quickly and easily perform transactions over an open network such as the 
Internet using a smart card. It is also desirable to have an architecture and system in which 
a user may use a smart card for both purchases over the Internet as well as purchases at 
existing service payment terminals. 

However, in order to purchase, the card must be loaded with value first. Value can 
be loaded onto a stored- value card in |i variety of way s., Currentiy , it ^:>P??"Vf5Aient for^^ . 
user to load Value onto hfs or her stored-value card. A user must physically travel to a bank 
or other institution that has^ automai^^^ (AT?^)j9r 9^?^; X'™*^^^ 





V order to ipad value pri tQ^^^ The user can insert money into the 

V' machine and have a correispbnding value put dnto the stbred-value cMd,^^^ a 
debit card to deduct ya^^^ 

credit card can be*!^^ as the source of funds to be transferred to ,the stored-value card. 
5 - In either case, the liser must travel to the bank to load value; Furthe creatine difficulty is 
. that not all banks or other financial instituuons have such a machine for loadinc value onto 

- -r . .-^^>5a user's stpred-vsdufe^card^k?^^^ 

- . Accordingly,' it would als^^ 
conveniently arid easily load value onto* a stored- value card.^ ' 'il^ ^ ^ ^ 
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To achieve the foregoing, and in accordanpejlw purposes of the present ' 
invention, an airhitectiare and system is disclosed that enables the use of a smart card for 
payment of goods and/or services purchased on-line over an open network such as the 
IntemeL Further, an architecture and systerh is disclosed that enables a smart card to be 
loaded with value on-line over an open network such as the Internet. 




In a first aspect, the present invention provides an electronic commerce payment 
solution offering consumers an on-line equivalent to purchases \yith cash or coins. It 
extends the notion of a smart card to the Internet maricetplace, providing an alternative for 
low- value transactions. The present invention facilitates not only the purchase of physical 
20 goods, but also the purchase of digital merchandise (such as electronic information). 

In one embodiment of the present invention, a client server on a client terminal 
controls the interaction with the cdnsunier and interfaces to~a c^ reader which accepts the 
consumer's smart card, which, in one specific embodiment, includes a stored- value 
application. For the purposes of this description, the smart card with a stored-value 

25 application used in embodiments of the invention will be simply referred to as a "stored- 
value card." A payment server on the Internet includes a computer and terminals'that 
contain security cards to handle the transaction, data store and collection. Also connected 
to the client terminal and the payment server over the Internet is a merchant server 
advertising the goods and/or services offered by a merchant for sale. In one embodiment 

30 of the invention, the merchant server includes a web site and the merchant has contracted 
with an acquirer to accept stored-value card payments for goods and/or services purchased 
over the Internet Thus, a consumer may use his or her stored-value card at a client 
terminal location in order to purchase goods and/or services from a remote merchant server. 
The Internet provides the routing functionality among the client terminal, merchant server 

35 and payment server.^, ; ~ . ^ v;/'''.- "V'^ " ■ Z^^'^^^ii.^^ ■'^^^■y^-''}^^:^^^-'!:' - 
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- From the consumer's perepecti^ inasimilar.: 
fashion as using a stored-value card in a real merchant environment The transaction 
reprocess is similar to' the interaction between a stored-value card and a service payment 
terminai in a face^to-face merchant environment, but with functionality distributed across 
the Internet between the card reading device located where the customer isi the merchant 
seiVer advertising the merchant's warM, ajtid a paymen^^ that 
manages the transaction. All of these entities may be physically :remote from one another 
with router functionality being provided by the Internet-^ The 'pieseii is easy to - 

use. A consumer need not establish a new relationship widi a bank or other Internet service 
corhjpany, nor create a special Internet deposit account in orde^r to begin purchasing go^s \ 
arid/or services oh the Internet. A consumer simply makes use of cumritly availabie; ' 
stored-value cards in order to make an Internet purchase.'^:' \' * '!'"[ ' * : : ' 

When browsing merchiarit store fronts on the Internet and deciding to purchase gbods 
and/or services, the cardholder selects the stored-value card payment option offered by the 
merchant. The cardholder then inserts his or her card into a card reader attached to a 
personal computer (for example). The cardholder's balance and purchase amount are 
displayed, the cardholdCT approves the purchase and the amount is deducted the 
value stored on the stored-value card The transaction amount is captured by the security 
card or the merchant server ifor subsequent batch settlement through a clearing and : 
administration system to the issuer mid acquirer. In one cmbckliment, the transaction ' 
security and authentication for the system follows a similar methodology as that used in an 
actual service payment terminal between a stored-value card snd the security card in the 
terminal. Advantageously, a customer rnay niake use of prenexistirig stored-value cards for 
purchases over the Internet without any prior amhge^ ^ 
credits or tokens, or establishment of a new relationship with a bank or other company. 

In addition, once a value has been deducted from the stored-value card, the 
merchant has been informed, and the security card in the payment server has recorded the 
transaction, an existing clearing and administration system may be used to reconcile the 
transaction and to pay the appropriate parties. Advantageously, a new system and 
methodology for reconciling transactions need not be developed or implemented, A pre- 
existing clearing and administration system may be used which grcatly siinplifi^^ ; > 
implementation of the present invention. >^ . ^ - ^ v - i 



Use of a stored-value card as payment for Internet transactions provides numerous 
advantages. For example, a stored-value card can be used in small transactions wherej 
35 credit cards or checks would be unrcalistic. ; Other advantages tplhe coriVuSi^f-jS'clude^ 
enhancing the value of a stored-value card by enabling access to" both real and^lBtffi 
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, .anonymous p^men^^^ over open networks. Furthermore, in one 

embodiment of the ihviehtioh'the stored-value card is implenierited bh a traditional credit 
card; a singlejcafd dius provides p^ solutions for both lo^y and high value 

'transactions/;^^:^■>^:-\:-o^:^^^ ' : ' "■ 

>^ In addition, use of a stored-value card is extremely advantageous for ismall dollar - - 
amount transactions are reluctant to .use, and merchants are reluctanUo , 

. . accept, credit ciu-d, bran f or sniall dqllar amounts. For thjELConsumer and the . , ^ . 

J merchant dealing witJfi many of these small transactions can be a bookkeeping headache and 
may not be worth the expense, A merchant may also be unlikely to acxept a credit card for 
a small dbllar amount transaction because of the service fees per transaction. By permitting 
the use of a stored-value card to miake purchases over the Internet for small dollar amounts, 
a merchant may be able to begin charging for goods and/or services that he had 
been providing for free in the past. One embodiment of the invention works well with 
purchases of under $ 10.00, although purchases of any amount may be made. 

The present invention also provides numerous advantages to merchants who wish 
to sell goods and/or services over the Internet. For example, the present invention provides 
a payment solution for low- value transactions, enabling'merchants to offer a wider range of 
digital merchandise. A merchant is also provided a method to recover costs of services not 
previously charged for, and is provided immediate access to an existing, and rapidly 
growing, cardholder base. Furthermore, the present invention integrates into an existing 
clearing and administration system meaning that the merchant need not implement or 
become familiar with new procedures for reconciliation of transactions. 

Furthermore, a merchant need only make a minimal investment in time and money to 
take advantage of the present invention arid to accept payments over the Internet. The 
merchahVrieed not engage in the development of complex software or accounting 
procedures. Thus, smaller merchants will especially benefit from the present invention. 
By establishing a business relationship with an acquirer and incorporating standard 
merchant software, a merchant is ready to begin selling goods and/or services from his web 
site. Because a smart card with a stored-value application is used, the payment server and 
the client terminal perform the details of the transaction and a merchant is relieved from 
having to control and keep track of a transaction. Also, the payment server and its 
associated security cards manage and provide security for the transaction. From a 
merchant's point of view, the merchant knows that a consumer desires to purchase an item 
and that a cost has been transmitted to the consumer, thus, when the merchant receives a 
confirmation message, the merchant may release the item to the consumer. The merchant 
need not be concerned about security nor be responsible for authenticating a stored-value : - 
card nor for determining a balance on the card. Of course, a payment server could coexist o 




along with' tlfe nie^ server or could even bfe th^ sime compuien That is, a merchant 
could implement payment server functionality at its own site if it so desired. 

In a second aspect of the present invention, a loading technique allows the consumer 
to conveniently load value on to his"or hbi^stor^-yalue card fromf any suitable device via an 

5 open networic such as the Internet. -A consumer is allowed to use any suitable computer at 
the home; office or elsewhere in order to'cbnnect to his bank of other financial ihstitutionr"-^" 
Using appropriate rnessage integrity; yjiluc is transferred frdm.the^bank 
stored- value catd. At the same time, the corresponding value is transferred from the bank 
to the stored-value card issuer through existing networks for later settlement with a , r 

10 merchant from whom the consumer purchases goods or Services; fAdvantageously, this 
embodiment makes use of an existing clearing and adniinistratioh system for eventual 
setUement of the transaction between the merchant and the card issuer. Also, the 
transaction is fixliy auditable and a log of previous transactions is stored on the card for later 
display. Thus, a consumer may conveniently load value on to his or her card while a high 

i 5 level of security is maintained and the card issuer can take advantage of unspent funds on 
the card. 

From the consumer's perspective, the present invention operates in a fashion 
similar to loading a stored-value card at an ATM machine, except that the consumer need 
not insert cash or an additional debit or credit card, nor need travel to a bank. The loading 
20 functionality is distributed across the Internet between the card reading device located 
where the customer is, a bank server holding the consumer's account, and a load server 
with a host security module that provides security. All of these entities may be physically 
remote from one another with routerjunctionaiity being provided by the Internet. 

. Furthermore, a bank need only make a minimal investment in time and money to take 
25 advantage of the present invention in order to allow its customers to load value from their 
existing accounts over the Internet. The bank need not engage in the development of 
complex custom software or accounting procedures. By incorporating software libraries, a 
bank is ready to begin loading value onto its customer's cards from its web site. 
Preferably, libraries are provided that interface with an existing server at a bank to facilitate 
30 the building of an HTML page. Because a smart card with a stored-value application is 
used, the bank server, load server and client terminal perform the details of the transaction 
and the bank itself is relieved from having to control and keep track of a transaction. Also, 
the load server and stored-value card manage and provide security for the transaction. I.e., 
the bank need not be concerned about security nor be responsible for authenticating a 
35 stored-value card nor for determining a balance on the tiard. Of course,~a load server could 
coexist alongside the bank server or could even be the same computer. That is, a bank 
could iihplenient load server functionality at its^b^ 
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ernbodiment; the load server aiid Its security moaule is provided by a separate financial " ^ - 7^-- =^^^ 
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benefits to 

issuere^d'acquirei^ the functionality for a stbred-value card increases 

revenuelpi^^ cardholders arid merchants.^ Also, there niay be new merchant 

ihaifetirig pp^ present invention also qffer^ tnicrb-payment ^ ; - " " v^^^S 

solution_for electronic ccH^ need to intn>(luce^^ separate product or brand ^ - 

or to establish new^^^ laadditipn, in one specific embodiment 

of the invention, funds that arc loaded onto a card are transferred from the loading bank to 
the card issuer so that the issuer m£^^ jSke advantage of the funds on the card until diey are 
.spent. ■' ' _v . ■ \ V • ^--^ 
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A further advantage of both aspects of the present invention is its ability to minimize 
transaction traffic on the Internet and to minimize the amount of time that a security card (or 
a security module) is tied up with one transaction. In the payment aspect, by emulating 
security card commands issued to a stored-value card, a client terminal is able to receive 
and group responses for transmission to a payment server all at once, rather than one-by- 
one over the Internet. The payment server is then able to emulate a stored-value card as it 
interacts with the security card in delivering the responses to the security card. The result is 
less message traffic over the Internet, saving time and interrupts. 

Also, by delivering an expected stored-value card signature to the payment server, the 
security card is relieved from having to compare the signatures itself, and may release 
sooner and move on to a new transaction. The payment server may also deliver the 
expected stored-value card signature to the client terminal or merchant server for 
tonqiaiisonf thus r^ one round trip the message traffic between the payment 

server and the client terminal. 

The present invention is suitable for use with any type of stored-value card that is 
able to store an amount and to decrement a value upon a command. In one embodiment of 
the invention, a stored-value card implemented as a processor card works well. Use of a 
processor card has advantages where information processing is done on the card rather than 
in the terminal or host computer. Processor cards allow encryption to be done by the card, 
allow generation of signatures, and can accommodate multiple passwords or personal 
identification (such as biometrics that uniquely identify the holder of the card). Processor 
cards also provide increased data security, an anti-fraud capability, flexibility in 
applications, a multi-purpose capability, and off-line validation. Because high 
telecommunication costs and/or low reliability of a network may make on-line authorization 
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: : * . together with further advsmtages^ t^^ 

:z,drawings;in which: ^ ...i. ^;:vii^i^7^'-:^;^^^tti^^fe^ •/ :■ ' ' t' :" ■ .... 



; HG; 1 is a bIcKk diagram of an example of a s^^^ ; 
embodiments of theipre^ " '' J^^-!^^ 

FIG, 2 is a block diagram of a service paymenrtemunal in which a stored- value card 
10 may be inserted to purchase merchandise. .. . ■■■l,\U4Svii'.i-i'^-^jt-!^.'.>.-^ 

FIG. 3 is a block diagra;n of an example of a clearing and administration system 
useful for reconciling financial transactions received from a service paynieht temiinal. 

FIG. 4 illustrates an architecture and system for payment over the Intdmet using a 
stored-value card. . 

1 5 FIG. 5 illusteates a payment embodiment of the present invention. 

FIG. 6 illustrates another payment embodiment of the present invention in which the 
security cairl releases earlier. 

, .^--FIQ. 7 y.®^ ^ invention having 

fewer round trip ipessages^ cljent terminal and payment server. 

20 FIG. 8 illustrates still another payment embodiment of the present invention in which 

the merchant server compares stored-value card signatures. 

FIG. 9 illustrates an added encryption layer useful for embodiments of the present 
invention. 

FIG. 10 is a flowchart describing a user's perspective of a stored-value card purchase 
25 transaction using the present invention. 



FIGS. 11 A- 1 ID are a flowchart describing the processing of a user purchase using 
an embodiment of the present invention. 



^#f!^i^^^#'AVO 98AI9658 

V - / f^G- 13 IS a flowchart descnbm^^ 

FIG. 14 is a flowchart describing the alternative embodiment of FIG. 8. 
HGSM 5 A and 15B arc a flowchart describing the added security layer of no 
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"FIG. 16 .illustrates an for authentication bve^^ internet using 

a;Stored-v£UuejCvd.^5^y^-^^^ --r^-^^^-^ r^^^yk^j^si^ v 

HG. 17 illustrates a system.for loading value onto a store d-va lue card.according to 
oneembodirnentbf the present invention: "^^^^^ p 

FIGS. ISA- i SD. are a flowchart describing J^^^^ loading of a consxiiiier's^^^ 
card using an embodiment pf the present invention; : >^^^^^^^^^^^^^ 

FIG. 19 is a block diagrarri of a typical computer sys tern suitaW in 
embodimcntsof the present invention. ■ - ^ i:; :v , 




DETAILED DESCRIPTION OF THE INVENTION 
GENERAL ARCHrrECTURJE 

The present invention separates the functionality involved in a transaction using a 
1 5 stored-value card in order to take advantage of the routing capabilities of the Internet, FIG. 
4 illustrates symbolically an architecture 200 for an internet payment system involving a 
smart card, such as a smart card having a stored-value capability. An internet loading 
system is shown in FIG. 17 and may have similar functionality as described below. 
Shown is an internet 202, a client tehninal 204, a payment server 206 and a merchant 
20 server 208. Local cardholder functions including a consumer card interface, display and 
accept/cancel options are performed at client terminal 204. Payment functions including 
security card control, data store and use of a concentration point are performed by payment 
server 206. The presentation and eventual delivery of goods and/or services by a merchant 
are performed under control of merchant server 208. The internet 202 performs routing 
25 functions between each entity. It should be appreciated that internet 202 may take the form 
of the Internet currently in use. or may also be any other open network implemented using 
any combination of computer, telephone, microwave, satellite, and/or cable networks. 

Basically, client terminal 204 controls the interaction with a user and interfaces to 
card reader 210 which accepts a smart card having a stored-value application. For 
30 simplicity, throughout the remainder of this specification, card 5 will be referred to as a 
stored-value card (SVG) 5. Payrnent server 206 conifriunicates directly with a teirminal or 
through a concentrator 212 that handles ahy number of terminals 214-216 each having a 




security card 218 and 220 rcspective!J^ Pay^ 

concentration point 68 for transmission of transaction data to a clearing and administration 
system. Database 223 stores all suitable information passing through payment server 206 ■ 
for each transaction. Use of such a database a^ (or merchant 

servers) to use payment asrver.2b6 for transactions. ^ Payment s^ 206 controls payment 
functions such as handling the attached teririinalsrmauiaging^ base 223 and collection 
functions/ Merchant server 208 is a site jR^ fi^feonttaS^^ with ah aiiquircr to accept ' 
stored-value card transactions as payment for goodsand/prseryicespurchasedo^^^ . - 
Internet : / ^ ^ ^ ; -v 
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Stored-value card 5 may take a variety of forms and is useful in many situations 
where itis desirableto storempnetary valuepnacardthat aconsum^^ . . 

general/a stored-yalue card is any card or siniiiar device that is able to store a value that is 
decrerhented when the card is used. The card may be purchased complete with a stored- 
value or value may be later added to the card by a user. Such cards may also have their 
value replenished. Of course, a stored-value card need not be in the form of the traditional 
credit card, but could appear in any form and of any material that is able to store value and 
be manipulated by a user for a payment transaction. By way of example, odier forms that a 
stored-value card may take are any electronic representations. Further, the functionality of 
stored-value card 5 rnay be implemented in software on client termiiial 204, that is, card 5 
may be a "virtual" card. ^-y:' _ , :y ■ -^'^L'..- - : . 

A stored-value card may also perform a variety of furictions.iri addition to simply 
storing value. A card may be dedicatedjp.the storing value or may contain memory and 
programs for other applications as well.^By wa^^ refers 
to a processor card that can execute a'vffieQrbf 

functions. Such a card may sefve^debit,"credit, prepayn^^^ functions. A stored- 

value card typically includes information such as a bank identifier number, a sequence 
number, a purchase key, a load key, an update key, an expiration date, a transaction 
counter, a session key, etc., in addition to a running balance. '''' " 

A stored-value card may also be termed a prepayment card, a cash card, or a ^ 
decrement-in-value card. A stored-value card may dso be implemientied by using a variety 
of card technologies. By way of exanriple^ a stored-value cafd is t^ as a ■ 

card containing one or more integrated circuits. One exsmpie of an integrateid'circuit card is 
a memory card that has a semiconductor device for stonrig infoririSiron but lacks 'ci^lcu^^ 
capability. Another example of an integrated circuit card is a processor cai-d that^ ■ 
only memory but also a ipicrocontroUer to to~m^fe:decisjon^:7 
card may also be termed a microprocessor card or a 'Jsmart ciard'liSV 
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" " -A prdcessbrcara may.include an encryption module in order to provide a variety of 
security precautions.. By way of^example, security precautions may include simple PIN 
numbers, biometrics, simple' algorithms,;^ algorithms such as the Data 

Ericryptioh"Sl£uidi-d The card is ' 

5 thus able to use these precautions to j/OTfy^usra card readers, etc., to validate security 
: cards1ah"d/or to provide a u^^^^ ihdudes imy number of keys 

generate signatun^f^^ 

1 /moduli and - : ; - 

-y^fciiient'tenn card 5 

and for.conimunicatmg oye^^^ server or a merchant server. By way 

of example; cHe^ computer.fa^w^^ station, a personal 

computer, 'a kiosks or any type of service payment terminal that a consumer might use to 
purchas'elgocM^ services.' Fui^ermore, client tcrrnihal 204 may also be embodied in 

any poitable^d^^ as a l4>top coniputer, a ceiluiar telephone, or any variety of a 

personal digital assistant (PDA) such as those made by Apple Computer, Inc. or by U.S. 
Robotics: Card reader 210 is any suitable interface device that functions to transfer 
information and commands between client terminal 204 and stored-value card 5. By way 
of example, card reader 2 1 0 may be a card reader manufactured by Fischer-Farr 
International of Naples, Florida, by Hewlett-Packard of Palo Alto, California, by 
Schlumberger, by Gem Plus, etc. Card reader 210 may take any variety of forms such as a 
stand alone unit, integrated with the client terminal, attached to the keyboard of the client 
terminal, or even built in to a floppy disk-sized unit capable of being read from a disk drive 
of the client terminal, etc. ^ 
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Client terminal 204 includ^ client c 224 and card reader module 226. 

Reader module 226 may be irnplemented using any suitable software and libraries for 
communicating with card reader 210 and its actual implementation will depend upon the 
type of card reader used. Clieht'module 224 controls communication between the client 
terminal, the card reader, the payment server and the merchant server. Client module 224 
may be implemented using any suitable code. In one embodiment of the invention, client 
module 224 is implemented using a combination of "C" code and a Java applet. The applet 
is also supplemented with parameters frorn an HTML page sent from the merchant server. 
It is contemplated that Java code works well for implementing the modules on the client, 
payment and merchant servers because it is platform independent, and could even replace 
the "C" and "C++" code used. 



Client 'module 224 is also responsible for controlling displays to the user ahdjf or the - i-^r^i;^ 
interaction between the card and the card reader. The module also biiiids the draw request V . ^- .r^^^^-^w^^^M^M 




, . purchase from the iherch^t server. The client module is able to cpmmunicatewith all 
-components on the Internet^ either directly or iridiiwtly/^y^^^-^^^^^ a^. : - \~ .t^ - 

Payment server 206 includes payroent cc^c module 228 and terminal interface 230. 
5 As with client terminal 204, payment server 206 may be implement^ using any suitable 
- cornputienrBy way of example, a personal computer works well.-^fThere may be one w 
payment server for each merchant server or a single paymerit server may service any 
^ , number of merchant servers. Alternatively, there may be rhultiple payrrient servers for a 
single merchant. In addition, payinent server 206 need not be reniote from merchant server 
10 208 biat raiay be located at the same site and have a different Internet address, or the ^ 

payment server and the merchant server may eyen be implemented on the same computer. 
Payment server 206 is designed to facilitate the conrununication between the user's stored- 
value card and a terminal's security card. If a part of a transaction fails to complete, the 
payment server may notify the participating system components. 

15 ' Payment module 228 may be implemented using any suitable code. By way of 

example, payment module 228 is implemented using a combination of "C code, "C++" 
code and Java code. Payment module 228 is, in one specific embodiment, a multi-threaded 
process that can service multiple concurrent client applet transactions on demand. The 
module is responsible for controlling all interactions with the terxnirials and their 

20 concentrator including the transaction collection function. For individual transactions, the 
payment module controls the message flows and logs interim results. When an s^plet 
connects with the payment server, it creates a transaction thread to support the transaction 
through its life cycle. Each thread, in tum, assigns a terminal for communication. Having 
a one-to-one correspondence bNet\yeen transaction threads'arid terminals has teen found to 

25 provide desirable results. 

Terminal interface 230 is any suitable set of software and libraries for communicating 
with a terminal 214 either directly or, as shown, through terminal concentrator 212. The 
actual implementation of terminal interface 230 will depend upon the type of terminal used. 
A terminal such as 214 may be any suitable terminal such as are known in the art. By way 

30 of example, an iq Delta 2010 terminal made by Schlumberger has been found to provide 

desirable results. Such a terminal may support a variety of commands originatitig from the 
terminal interface. These commands emulate the normal responses that an attached terminal 
would pass from the stored- value card to the security card. The actual security card 
commands are held in the terminal while the terminal performs the tasks necessary to 

35 simulate, the presence of a stored- value card. 





^^_.^;r^-L- 
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; art 



.v^d^ Secunty card[218 mayjbel^ security card suchlas arc known iii the z 

/ (often jefenred to^a?a;Purchase Secure Application Module-PS AM). In other 
embodimen'tsrtiiefu^fi^^^^^ by a hardware security 

module, could bdjmplement^ in har^dwarc withm the payment server, or could even be 
5 implemented in softwa^ 
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% 218 is a rtsmpvible credi^card^^ 

ffiaf irp^ 
. card2j8^^^ 

authenticaWarid to validate the user's stored- value card/ If a user stored- value card is 
accepted jby the security card, and the stqred-vaiue card contains sufftcient value, the 
V security cai^^ that the merchant providing the goods and/or services receives 

^paymeht^^a^^^^ anfiduht deducted from the stored- value card for the goods and/or 

services rendered. In a preferred embodiment, the security card also contains DES 
purchase security keys and authenticates the stored-value card during a purchase transaction 
^ and secures the payment and collection totals. A security card also stores signature 
algorithms for stored-value cards in use, A security card may also contain a transaction 
identifier for the current transaction, a financial sum of all transactions remaining to be 
settled, a session key, and master keys for all stored-value cards in use. Further, the 
security card may contain generations of keys, blocked card indicators, date of last update, 
multiple card programs, different currency rates and additional security. 

Concentration point 68 is a staging computer that communicates with terminals to 
collect batches of purchase transactions. The concentration point then sends these 
transaction batches to a clearing and administration system for processing. Once ' 
processed, batch acknowledgments, along with other sy stern updates, are sent back to the 
terminals via the concentration point. 

)i ■ 

Merchant server 208 includes a merchant code module 232. Merchant server 208 
may be implemented upon any suitable computer capable of communicating with and 
presenting information to users over an internet. Merchant code module 232 may be 
implemented using any suitable code. By way of example, merchant module 232 may be 
implemented using a combination of Peri, HTML, and Java code. Merchant server 208 is 
typically a generic web server customized for the merchant's business. Merchant server 
208 may include databases, CGI scripts and back-office programs that produce HTML 
pages for an Internet user. 



'.' - *.<) - 



A brief discussion of the flow of a transaction now follows. During a financial 
35 transaction, the client terminal and merchant server exchange infomation 234 via internet^: - ^rr-^-K ^g, 
202. Each transaction initiated by a user has a transaction identifier created at the merchant ^ ; . 
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s rver, and a merchant idehtifier unique to the paymwit^erver is^^ from the 

merchant server. Client module 224 and the payment server also use this .unique 
transaction identifier for tracking and logging information aboiit t^^^^ 
server 208 generates a unique identification of the transaction, completes other required 
. - 5 parametersV encrypts as appropriate, and builds an HTML page and sends it to the client - 
' terminal. The client module interacts 235 vvith jtfie stored-value card and builds a dravy 

request message coritairiing related card infomia^ other ^ 

information supplied by the merchant server, ^.y .^^^^ : 

The client terminal then conununicates 236 with payment server 206, first by 
1 0 forwarding the draw request to the payment server. Payment server 206 verifies the 

. transaction to detetTTiine if it is a yalid transaction from a known merchant The transaction 
is logged into tiic payment server' s transactibh database 223. Upon completion of a 
transaction, payment server 206 builds a result message containing the identification of the 
transaction and signs it. The message is then routed to merchant server 208 via client ' ^. . 
1 5 terminal 204. Merchant server 208 then validates the result message. After determining that 
the transaction was successful, merchant server 208 creates an HTML page for the 
purchased information and sends it to client terminal 204. Alternatively, the merchant rnay 
also deliver purchased goods to the user at this point. It is also possible for the payment 
server and the merchant server to communicate information 238 directly between . 
20 themselves. Preferably, as client terminal 204 has already established communication with ; . 
the merchant server and the payment server, links 234 and 236 are used to exchange 
information between the payment server and the merchant server, rather than establishing a 
new link 238. 

~ — USER PERSPECTIVE OF A PAYMENT TRANS A 
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FIG. 10 is a flowchart describing an embodiment of the present invention from a 
user's perspective such as may occur with the embodiment of the invention shown in FIG. . 
4. In step 502, a user acquires and adds value to a stored-value card. Alternatively, a user 
may acquire a stored-value card that already contains value. This stored-value card nriay 
take the form of any of the above-described stored-value cards that are able to store value 
and to debit value from the card. In step 504 the user accesses the merchant server web site;; 
via communication link 234 over the Internet. This access of a web site may be performed ;~ , ^ ^ , . . 
in any suitable fashion such as by using any commercially available web browser. In itep <^ 
506 the user inserts a stored-value card in card reader 2 10 at the user's terminal. w - t% )^ j ? 

Alternatively, the user may insert the card before accessing the web site, or even after the ' _ ^ 

and/orservices from the merchant w^ step:508 the user J^Miiiy^yitt 

browses the merchant web site and selects goods and/or services for purchase from the '^'^^'^'^f^^^^^^ 
l^^^-trw^rch^^ web^site interface that theVnerchaSit hasi piwi 
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an appropnate button on the merchant web Site to indicate what the ^ " 

purchase. Next, in step 5 lOthe user receives a total saleamount froni the merchant server. - 

-•: • ■ ■ .r*- V^-'^'*^^::?'^^^^^ - 

and is directed to actuate a button on the web site indic£Uing that the user ^w to proceed 
with the purchase using the stored-value card.^ ■ : ? ^^f ;*^ ; - - 

; ;IiLste|) 512,the;a^^ shown „ 

in nO; 4, for iexample) processes die user b1*der by 'way t& tliifp^^ 
and secunty card. In step 514, the user s storM-value card is ^debited by the total sale 
amount and the user receives^ a "debited" m message is *~ 

optional if the system is designed so as^tp^^^ step 51(5 the 

user receives a confirmation message from the merchant server^mdicaung that the 
. transaction has been completed. ^P^JP^flMCP^^^^^^ infomriatioh 

and/or receive a receipt for gd6ds"ahd/6r servi^^ to be reriidered br'delivered from the 
merchant at a later date. In step 518 the merchant, yj 

system, receives payment to its bank account for' the gcw^' an^^ by 
way of information collected ifiom 

invention, an existing clearing and administration system is used, as well as an existing 
methodology for transferring information from a security card for later reconciliation. This 
use of an existing "back end" allows systems of the invention to be implemented quickly 
and cheaply. This approach also ensures that cards used in the system arc compatible with 
other stored-value terminals. . . _ _ . . , _ 




DETAILED PAYMENT TRANSACTION FLOW 



FIG. 5 illustrates a detailed embodiment of internet payment architecture 200 having 
client terminal 204, payment server 206 and merchant server 208:2 A stored-value card 5 is 
- ' in corifmunication with client terminal 204, and a"security~cai"d 218 inside a terrhirial 214 is 
25 in communication with payment server 206. Not shown for simplicity in this figure are 

other elements of the system shown in FIG. 4. One embodiment of a technique by which a 
financial transaction may be completed over the Internet will now be described using the 
flowchart of FIGS. 1 1 A through 1 ID with reference to FIG. 5, 

It should be appreciated that a wide variety of terminology may be used to describe 
30 message flow throughout the architecture. For example, the terminology used herein to 

describe the sequential messages draw request, debit, success, and confirniation, may also 
be referred to by the respective terminology: draw request, debit lEP, debit response, and 
debit result (or message result). 

Initially, a suitable web browser of client terminal 204 is used by the user to access a 
35 Imerchartt ^e^ by 302. In step 602, the user selects goods and/or 
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services ifrbih the merchant site and indicates to the site that the user wishes to purchase 
these items using a stored-value card as indicated at 304. In step 604 the merchant server 
receives this request for a stored- value cani tf^ ^ ^ 

In step 606 the merchant seiver buil^^ page that includes the following 

client ^plet parameters: the totd costlof t^^^ as determined by the merchant 

server; the type pf cunrency'beingTi^; and IP address of the payment server; a^^^^''^"^ 

unique transacUon identifier used 

track a transaction; and a unique mercKS^^ to the merchant by the 

acquirer jind known to the payment server. Other information may also be included such as 
the currency's exponent, a stams^UM;>d bf liiie merc^^^ used for 

communication from the client tenrunai, and ja merchant seryer generated key and other 
security information to ensure theJdeM the riierchant server and die integrity of the 
message. Other process related information such as software release level, encryption 
methodology and keys may also be conveyed. Price this page has been built, the page is 
sent 306 to the requesting client browser and triggers the loading of the client code module 
(in this example a Java applet) in the client terminal. 

Some browsers may not allow an applet to invoke a dynamic link library (DLL) due 
to security reasons. In an embodiment of the present invention, the client applet along with 
any DLLs needed are preloaded on the ciient terminal. Then, the nierchant server is 
allowed to invoke the client applet and DLLs dynamically to circumvent this security 
precaution. 

In step 608 the client rriodule of the client terminal interacts with stored-value card 5 
to.obtain.cardjnformation 308 iri ordef^o build a draw request message for later ' 
transmission 3 1 0 to payment server 206. In one embodiment of the invention, the client 
applet loads a local DLL, makes an API call to that library, which in turn makes a call to 
another DLL that finally makes a call to the card reader. In this fashion communication 
with the card is achieved. Once responses from the card are received, the client module 
will also combine these responses into a byte stream suitable for transmission over a 
network to a payment server. Also at this point, the currency type and expiration date on 
the card are checked, and the total cost of the ordered merchandise is checked against the 
card balance to ensure that the value on the card is great enough to cover the transaction. If 
the checks are not successful, a message to that effect is delivered to the user and this 
transaction terminates. 

; .The client module emulates a variety pf security card commands to receive responses - 
froiri these TO from the storcd-vaiiie card. Because the stored-value card and the . 

■^^Wi^yM^?^J\^ physically separated frprn one another, and communication takes M 
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" "- place over the Internet, U \yould iiot be m nunierous commands ' ^ 

and responses over such pen network. In the interest of speed and leli^ility, it is 
advantageous to have fewer messages exchanged. v : " - ^ . ■ 

To operate securely and reliably 
^ _ present invention, client module 224 emulates a security 'ca^ all the responses - . 

for transmission in one ctow rcqu^^^ include a 

^^yanety of in^^ ^u&fo^^ merchant - 

identifier, ihp transaction identifier, security informatipjn purse provy^^ identifier, an ; / : 
intersector electronic purse (DBP) identifier/sb' aigdnthm usefl^t^^ the'card, an expiry date, 
the balance of the card, a currency code, a cuniency exponent, t^^^^ mode of 

the lEP, the transaction number of the lEP, a key version and the pife amount. As all 
of , this information is prepackaged into a single dniw[requ<^ number of 

messages between the stored-value card and the security card over the Internet is greatly 
reduced. ' ' . ■ ■ . 

In this embodiment, the draw request message is built by packaging the stored-value 
card's response to the "reset" and "initialize" commands and any public key certificates 
along with the total cost and the currency of the transaction received from the HTML page. . 
For public key cards, the card and issuer certificates are obtained from read commands and 
may also be included in the draw request. By packaging all of this information together 
20 into one. draw request message, it is possible to cut down on the number of messages 
exchanged between the client server and the payment server, and reliability and speed is 
improved. In one embodiment of the invention, an intersector electronic purse (lEP) 
protocol is used to reset and initialize the card and to receive a response. 
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" i^ext; in step 610 the client termini accesses the payment server using the IP address 
25 received from the merchant server. In step 612 the client terminal sends the draw request 
message to the payment server as indicated at 310. The client terminal also creates a log of 
this message being sent. 



30 



35 



In step 614 the payment server processes the draw request in conjunction with an 
associated security card as will be explained in greater detail below with reference to FIG. 
1 ID. Draw request 312 is shown being sent to terminal 214. In one embodiment of the 
invention, the payment server creates a transaction thread for each connected client module 
to service it through the life cycle of the transaction. After step 614, the payment server has 
received a debit command and a security card signature 314 from the security card in the 
terminal. This debit command may also be termed a "debit lEP" command. The security 
card signature is a value that uniquely identifies and.y^idates.security cai^ 218 to^prove.to . 
stored-value card 5 that the incoming debit command is a valid command from a real - 





I'll' l^lfli^iTfli;^^^!^^ 
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security card. This validation ensures that when the stored-value card is debited, that the 
financial totals in the security card are updated. Thus, the user of the stored-value card is 

- guaranteed thai a valid debit of the card has occurred. In a preferred embodiment of the 
invention, the security card signature is an encrypted value ensuring that no other entity can 

5 forge an identity of a security card.-— ' ' - 

. jij'jtgp p^^^ along'with the security' "^" -"^^^ '-^^ 

card signature to the client terrniiial as indicated at 316 for^the stored-value card to debit . / . 11 
itself. At this time, the payment server also logs this debit conimand into its database. 

In step 6 1 8, upon receiving the debit command from the payment server, the client 
10 module replaces the amount in the debit conimand with the original amount (from the 

merchant server) to ensure that the amount has not been tampered with while traveling over 
the network. At this time, the client module also creates a log of the debit cornmand. - 
Client module 224 then passes 3 18 the debit command and security card signature to > . . - - 
stored-value card 5 which verifies the signature, debits itself by the purchase amounW and 
15 also generates a success message (also termed a "debit response" message) and a stored- - 
value card signature. The stored-value card signature is a unique value identifying a valid . — 
stored-value card. In a preferred embodiment of the invention, this signature is in 
encrypted form to prevent tampering. If card 5 does not have enough y^ue to satisfy the 
purchaseamount, then the "debit response" message indicates as such. r^^ . L 

20 In step 620, card 5 sends a success message 320 along with the card signature back 

to client module 224 in client terminal 204. This success message may also be termed a . 
"debit response" message. At this point, the purchase amount has been deducted from the 

- balance on stored-value card 5.;Next,-^in step's^ 224 packages the success 
message along with the card signature and sends them back to payment server 206 as 

25 indicated at 322. Client module 224 also logs the result of this stored-value card debit. 

In step 624 the payment server receives incoming message 322 and creates a log 
and updates the transaction status in its database for future error recovery. The payment 
server then directs this received message to the security card in the terminal as indicated at 
324. Next, in step 626 the security card processes this response from the client's terminal 
30 and verifies the received stored-value card signature. 

As the security card contains the keys and algorithms necessary to compute stored- 
value card signatures, the security card is able to validate that a received stored-value card 
signature is in fact a valid one by comparing this stored-value card signature with a 
* generated expected value. A successful comparison indicates that a success message 324^"^^^^ 
35 received from the stored-value card is in fact a valid success message and that the 
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Tjvzdiie card ^ - 
..potentially indicates that the stored^-value card has not been debited by the proper amount. 
This comparison of stored-value card si^a^ ensures that a stored- 

value card is iri f act debited before the merchant s^i^er^s^dircSited^ to the purchased - 

jrnerchandise. This comparison of the stored-yalue card signature to an expected value is . 
; performed by the security card for thei hig^ in the . 

:±5^n!>^<>diments of FIG^_6, 7, anci 8^ Ais cpm{^^ 

also take place in the payment server, in the ciient terminad or iii^ the nierchant seiner with ;^ 

- yjiriety of other advantages! rA^su^ 628 the 
security cai-d sends a "confirrnation*' messiage back tb.the j)ayment\^ indicatedjif : 
326. ' This confirmation niessage may also be termed a'\'message result," - / , i';: • - v ^ 

- ' - In step 630 the terminal updates its data store withjiw^^foin^ nurnKeir, a . ? 

transaction count, the total sale amount, the response from the security card, and " 
transaction numbers from the stored-value card and from the secunt^ The payment 

- server also logs the response received from the terminal including the merchant identifier, 
etc., as indicated in step 632. Next, in step 634, the payment server creates a confirmation 
message including the transaction identifiers and sends this message to the client terminal in 
encrypted form as indicated at 328. This message 328 may aJso be termed a "message 

.result." 



20 By sending this confirmation message in encrypted form, the confirmation messag;e 

may be passed to the merchant server by way of the client terminal without fear of 
tampering. As the confirmation message is encrypted, it would be extremely difficult for 
the client tenhinal or another entity to forge a confirmation message and trick the merchant 
- .-- :^!^r^^^^^^^J^^^^^^ ^ transaction had taken place. In another embodiment of the ^.^ :r 
25 invention, if the client terminal is a trusted agent, then the confirmation message need not 
be encrypted. In yet another embodiment, the payment server may sent two confirmation 
messages, one not encrypted for the client to process, and one encrypted for the merchant 
server. FIGS. 15A and 15B present an embodiment in which the payment server sends 
two messages to the client terminal. 

30 At this point, the transaction thread of the payment server that was used for the 

current transaction may release the terminal, thus allowing the terminal to be used by other 
transactions. This transaction thread dien exits at this time. 

In step 636 the client terminal then passes this confirmation message 330 on to the 
merchant server at the URL address previously received from the merchant server, 
35 ^Message 330 may also be termed a "message result." The client may also post a message : 
to the user informing that the debit has been completed. The client also logs confirmation 
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: checks for successl'^llie merchant server calls a validate routine within the merchant code 
^mwaduf^ with^^^^ in order to validate the response from the client 

Tlie i^idate rom^ to take the transaction identifier along with the encrypted ^ 

5 cbrifirriSatiori nfessage to decrypt the confirmation message. If the decrypted confirmation 
mc^sa^eTs accepSible,^'ffi^^ server then determines a successful transaction has 

" ciccu 

purchSed infornm to the client terminal. Alternatively, 

the rnercKanTserver may generate a puirhase receipt to deliver to the client terminal 
10 indicating gocwls and/oi* servic^^ rendered. At this point, the client teiminal may also 
log the merchant server's response. Completion of these steps indicates a successful ; 
financial transacti^^ ^ . y-:'-^- ■ 

Returning now to a more detailed discussion of step 614, FIG. 1 ID describes one - 
technique for processing a draw request message in conjunction with a security card. Once 

1 5 this draw request message has been received by the payment server and passed along to the 
terminal, the terminal parses the message back into individual responses and passes these 
responses sequentially to the security card as will be explained below. In an alternative 
embodiment, a dumb terminal is used and the draw request is parsed into its components 
and otherwise processed by the payment server, which then sends the responses to the 

20 security card itself. 

In step 680 the payment code module of the payment server edits the draw request for 
syntactic correctness and logs the draw request message as being received. In step 682 the 
draw request is passed to the terminal interface niodule of the payment server. In one 
specific~embodiment, the terminal interface then requests ia terminal froni the payment 

25 server's terminal pool. The payment server has a pool of terminals connected to the 

terminal concentrator that is established at start-up. At start-up, the payment server receives 
a list of all valid terminal identifiers. The payment server uses these identifiers, and its 
knowledge of transactions in progress to determine an appropriate terminal to process the 
transaction. Once a terminal is determined, the terminal interface builds a terminal specific 

30 message based upon the draw request and the type of terminal. 

In step 686 the terminal specific draw request 3 12 is sent to the chosen terminal via 
the concentrator over a local area network. The concentrator acts as a router between a - t 
transaction thread in the payment server and its corresponding terminal. The concentrator 
looks at a header on the draw request to determine to which terminal the transaction should 
35 . be routed. In one embodiment of the invention, concentrator 212 is remoyed^and payment^ 
server 206 communicates directly with terminal 2 1 4 (for example) . ^ . , 
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- components and processes eachcompionent:in tum to emulate a stored-value card 
/. mteractmg with the secunty card m a physical tenrnnal. PrepacIcaking of a vanety of 

; information into the draw^nequest messag in fewer exchanges over the Internet 

5 - between the .client terminal and the payment^ryer. By now simulating an mteracuon, the 
^security card behaves as if it werc in a physical tenninal along with the stored-value card. 
^ A variety pf^i^ the 
~ terminal sends i^^^ "iriitiaiiie'IEP'\ and "debit" 



jio\y a to. th auid Waits fo^^^^ meissa^ before sending the 

10 : next response/} Fo^ keyiransaction/die certificates read by the client are also 

included aSjh^^ responsies. ;In this fashion/eyen though ^all of the stored-value card 
info'ntiatioA (th^ terminal has been sent at once in . 

prcpiaclqiged the Internet fee tradiUonSlntei^tion between the stored-value card 

and the security card in a physical terminal may be simulated at the terminal in a remote 
15 location. - j\i • ■ :\ ■ V:^ 'v"::--/ , -i^-- 
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In step 690 the terminal reaches a "draw amount" state, indicating that the security 
card is able to generate a debit command. In step 692, the security card generates its 
security card signature and the debit command. The debit command may also be termed a 
"debit lEP" command. This signature and debit conunand 3 14 are sent to the terminal. 
The debit command issued by the security card may contain a wide variety of information 
including the security card identiiler, the^transaction identifier, the amount to be debited, the 
currency and currency exponent for the amount, the security card signature, the date, time, 
and location. The terminal in turn, sends the signature, command, and the terminal 
identifier to the payment server as indicated in step 694. The information may be sent to 
"the payment-sender as indicate^^ "Atlhis poirit/step 614 ends arid 

control returns to step 616. 

FIRST ALTERNATIVE PAYMENT EMBODIMENT 

FIG. 6 illustrates an alternative embodiment 200a in which the security card is able to 
be released sooner than the security card of FIG. 5; this embodirnent also requires fewer 
exchanges between the terminal and the payment server. A security card in a terminal is 
dedicated to a particular transaction from the moment when the terminal interface selects 
that terminal until the security card finally issues a "confirmation" message and is released 
by a terminal interface. Thus, in some circumstances it is desirable to release the security 
card earlier. By releasing a security card earlier, the card is tied up for a shorter time per 
transaction and may move on to the next transaction sooner. Also, the less time that a 
"terminal is d^icated tc) a particular transaction, arid the fewer messages exchanged between 




rW098AtW58 " 




^^^^ -^w^-i 



5. 



the two. the I^s likely chance there is of a coiranunication^errbr that might intermpt and 
halt the transaction. 

Embodiment ioOa includes a client terminal 204, a payment server 206, a merchant 
server 208, a stored^y^due c^ 5, an4 a terminal 214 having a security card 218. 
Communication between the various entities may take place in a similar fashion as in FIG. 
5 as indicated byxommunic^^^ links 234, 235, and 236. However,' instead of two round 
trips of informatioif between the tef^ and payment server, there is only one round trip 
in this embodiment. . i " - y-^.--- "~ / ^' .V; 



-FIG. 12 is a flowchart that describes a technique for implementing this embodiment 
1 0 with reference to FIG, 6. Step 702 indicateis that communication between the various 

entities takes place in a similar fashion as in FIG. 5 up until the terminal reaches the "draw 
amount" state.; At this point, draw request 312 has been received and processed by the 
security card. Next, in step 704 the security card generates not only the security card 
signature and the debit command, but also an expected stored- value card signature. This 
1 5 expected stored-value card signature is a value expected by the security card from the 

stored-value card to validate the stored-value card's success message. This validation will 
ensure that the stored-valued card has in fact debited itself. 



In step 706 the security card signature, the debit command and the expected stored- 
value card signature are sent to the payment code module in the payment server as indicated 
20 at 3 14a. Also, the terminal updates its data store in a similar fashion as in step 630. Next, 
step 708 indicates that the transaction occurs as before with reference to step 6 16-622. The 
steps indicate that the stored-value card receives the debit conunand, debits itself, and 
. returns:the.succcss mcssa^ (also termed a "debit response"- message) aind its card signature Vi^Tr-ff^^^ 
to the payment seryer.- - 

25 Next, in step 710 the payment server code module processes this response from the 

stored-value card by comparing 346 the received card signature with the expected stored- 
value card signature received earlier from the security card. This comparison of the two 
signatures by the payment module of the payment server foregoes the need for another 
round trip between the payment server and the security card. Because the security card has 

30 already delivered the expected card signature to the payment server, the security card may 

be released as soon as message 314a is received. • 

Assuming that the comparison is successful, the payment module is then able to ' 
generate its own confirmation message instead of waiting for a "confinnation"_message : 
' ' T from the security^card.iNext^^^ 712 indicates that the processing coiffiiiiies inXs|™& 
35 fashion as in steps 632-640. ^The confirrnation message is passed on to the merchant sej^^ 




nrp-pn^npn-^TT-^Tr^mn SB? 



.... i^:.^!-. ^ ..^S.^. 





vv^^mBm^O .98/49658 ^.^it;^. 



10- 



15 



20 



25 




'^by waylbf ti^ terminal and the merchaht>enw ^6n deliver the ptirchased j^^^^SgJI^ 

J:-:meirchandise to the user. - - ' * i; ^c,-. -^r^^^ - [^^^'■■:'''^'-'^'^^.:^.MM:^ 
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:^ ; ^: In another cmbcKlinie^ invention as j I lust^^ FIG. 7, not ; jjl^^^" 

:oniy Js the security card allowed to release ^rlier, but the' number of messages exchanged vr ^-^^^^0^ 

s bet^eeh thc! client tenhinal^and the paymeik s^ 

' st6red?value card si^atures in the paym^ server/the expepted stpred-ySue card "V!!:"' -: i^^^^ 

; tiromlh security canl is transniitted to the clier^ tehriinal^vhere a 356 - /^^^ 

perfbnns the comparison of the expected stored-vi ^ ' vM^^S^^v^^S^^ 

jsighature're^ from stored-value card 5. r^husJ^ ttiSBSsage: exchange bet^^^ the client : : .^""j^:. ^^^-^J^^^! i^fe^^l^^^ 

terminal and the payment server is reduced to one round trip. : This is advantageous in that , 

the time for a transaction is r<^ the isecurity card is released earlier and fewer message ! 

exchanges means more reliability over the Internet, • 

Embodiment 20db includes a client terminal 204, a payment server 206, a merchant 
server 208, a stored-value card 5, and a terminal 214 having a security card 218. 
Communication between the various entities niay take place in a similar fashion as in FIG. 
5 as indicated by communication links 234 and 235. 

' FIG. 1 3 is a flowchart that describes a technique for implementing this embodiment 
with reference to FIG. 7. Step 722 indicates that communication between the various 
entities takes place in a similar fashion as in HG. 5 up until the terminal reaches the *'draw 
amount" state. At this point, draw request 312 has been received and processed by the 
security card. Next, in step 724 the security card generates not only the security card 
signature arid the debit cbmrhand,-but also'ah^bxpeibted stored-value card signature. 



In step 726 the security card signature, the debit command and this expected stored- 
value card signature are sent to the payment code module in the payment server as indicated 
in 3 14a. Also, the terminal updates its data store in a similar fashion as in step 630. Next, 
in step 728 the payment server code module sends the debit command, merchant signature 
and expected stored-valued card signature to the client terminal. 

Next, step 730 indicates that the transaction occurs as before with reference to steps 
6 1 8 and 620. The steps indicate that the stored-value card receives the debit command and 
debits itself. In step 732, the client code module itself compares the actual card signature 
from the stored-value card with the expected signature from the security card. This 
comparison of the two signatures by the client module of the client terminal foregoes the 
'- need for another round trip between the payment seWer'ji^^ the client lefrninal. Also; p:^ 
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because the security card has already delivered the expected card signature to the payment 
server, the security card may be released as soon as message 3 i4a is received. 

Assuming that the comparison is successful, the client terminal is then able to 
generate its 9 w^^ message in step 734 instead of waiting for a confirmation 

message from the payment server. Next, step 736 indicates that the prbc^sing continues 
"in asimilar fs^hion as iri^s^^ 636-^0/ The confirmation ' 
merchant seiyei" and the merchant server may then deliver the purchased rnerchandise to the 



user. 




THIRD ALTERNATI\^PAYMEhrrEMBODIMEOT 

FIG. 8 illustrates another embodiment~200c of the invention in whiich the merchant 
server performs the comparison of the stored- value card signature with the expected 
signature. This embodiment has ail of the advantages of the previous embodiment in which 
the security card is released earlier, and there are also fewer messages passed between the 
entities. In this embodiment, if the client terminal is not to be trusted to compare the stored- 
vaiue card signatures, then an encrypted signature is passed to the merchant server via the 
client terminal. The client terminal also passes the raw, unencrypted signature from the 
stored-value card to the merchant server. A routine 366 in the merchant server then 
compares the two signatures. . 

Embodiment 200c includes a client terminal 204, a payment server 206, a merchant 
server 208, a stored-value card 5, and a terminal 214 having a security card 218. 
Communication between the various entities may take place iri. a similar fashion as in FIG. 
5 as indicated by messages 302-306 and communication link 235. ^ 

nai4 is a flowchart that describes a technique for implementing this embodiment . 
with reference to FIG. 8. Step 742 indicates that communication between the various 
entities takes place in a similar fashion as in FIG. 5 up until the terminal reaches the "draw 
amount" state. At this point, draw request 3 1 2 has been received and processed by the 
security card. Next, in step 744 the security card generates not only the security card 
signature and the debit command, but also an expected stored-value card signature. . / 

In step 746 the security card signature, the debit command and this expected ^tofed^^ 
value card signature are sent to the payment code module in the.payment server as |ndicat^ 
in 314a. Also, the terminal updates its data store in a similar fashion as in step 630. Next,; 
in step 748 the payment server code module sends the debit conirnand, rrieix:hantji^ 
and an encrypted expected stored- valued card signature to the cllent^te™ 
stored- valued card signature is encrypted to prevent tampering by t^^^^^ 
other-outside entity. ' - ' •\;v^.-..v^r7^3:S^^^ -^^-^--^--^ 





ii; - 7 : . ^ Next, step 750 indicates that the,trari^ 
~1 618 and 620. The Steps indicate that the s^^ 

debits itself. In step 752, the client code module sends the success inessagc, the raw 
' ~ ' stoi^-value card signature dind the ericr^ 

5 754 the merchant server processes the success message, decrypts theenctypted signature, 
' and compares the two signatures. This comparison of the two si jgjiaturc^^ 
^ /server foregoes Uie need for imother round trip between Ae pa^^ 
terminal. Also, because the security card has already de^ 
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to the payment server, the security caid may be released as soon as "me^sa I4a is : 

received."'' ^. ' - ' ' - -^r-^':-;'- ^.^ -'-^ 
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Assuming that the. comparison is successful, the merchant server is th^n able to 
generate its own cbnfiiroation messa^^^ in step 756 instead of waiting for a confirmation , \ 
message from the client terminal. Next, step 758 indicates that the processing continues in 
a similar fashion as in step's 638 and 640. The merchant server may then deliver the 
purchased merchandise to the user. In all of the above alternative embodiments, when the 
transaction is not completed successfully, the payment server reverses the transaction 
within the terminal. 



ENCRYFnON LAYER EMBODIMENT 

FIG. 9 illustrates an embodiment 200d of the present invention in which an 
20 encryption layer has been added. Although the present invention may be practiced without : 
this added encryption layer, in a preferred embodiment of the invention, this encryption 
layer is used. FIG. 9 includes client terminal 204, payment server 206 and merchant server 
208. Other elements of the jirchitecture have been omitted in this figure for simplicity. 
"This extra enciyption layer is used hot ohly^to protect the "cbntents o^^ 
25 transnlitted over the Internet, but also to prevent a client terminal, stored- value card or other 
entity from receiving or producing a message that would trick another entity into thinking 
that a valid transaction had occurred. This encryption also prevents messages from being 
accidentally or deliberately altered or misdirected. 

It should be appreciated that encryption may be present in any embodiment on all 
30 parts of any message sent for security. Preferably, any signature sent over a network is 
encrypted. 

Figures 15 A and 15B arc a flowchart describing this embodiment of the invention 
with reference to FIG. 9. In step 802, the payment server and the merchant server share a 
unique encryption key. Through a pripr business an"angement, both pf the ser/ers Jhaye 
35 arranged to share this unique key to add security to the transaction^ The sh?^^ key ixiay be' 
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,of ail)^suitab^e e of any length. The key .may .be a Data Encryption . 

Standard (DES) key having a length of 128 bits including parity. Although this shared key 
' could be used directly, in a prefen^d embodim^ of the invention; there is a derived 
unique key for each transacdqn between the rnerchant server and the payment server. 
5 ^- Alternatively, another encryption standard such as BSA may also be used. Preferably, 

loading of yalue is performed under DES. while a purchase may be performed under either 

^ In step 8Q4 the client terminal and the men^hant server engage in a protected Secure 
Sockets Layer (SSL) session 404 in which a'cohnection is made, a user browses and 
10 makes a purchase selection. The SSL session prot«:ts the infomiation transmitted over the 
Internet such as card information, commands, and encryption keys from being discovered 
by an unauthorized party. Other techniques for protecting a session may also be used. 

, In step 806 the merchant server derives a key from the DES key using information 
unique to the transacdon such as the merchant idendfier, the transaction identifier, or other 

15 information unique to this transaction, such as a random number. Because the payment 
server shares the DES key with the merchant server and also has access to this unique 
information about the transaction, the payment server will also be able to derive this same 
key from the shared DES key. In this step the merchant server also creates a transaction 
session key (TSK) for use by the client terminal and payment server in encrypting 

20 information. 

In step 808 the merchant server downloads an HTML page of information 406 that 
includes the TSK and the TSK that is encrypted using the derived key (ETSK). The TSK 
encrypted with the derived key will be used by the payment server to return an encrypted 
(and unreadable by the client) confirmation message to the merchant server. Only the 
25 merchant server will be able to decrypt this confirmation message and will thus be 

guaranteed that a successful transaction has occurred and that merchandise may be released 
to the client. 

In step 810, the client prepares the draw request in conjunction with the stored- 
value card and sends the draw request 408 encrypted witii the TSK to the payment server 

30 along with the ETSK. In step 812 the payment server uses the shared DES key and the 
prearranged information unique to the transaction to derive the same key that the merchant 
server has used. Thus, the derived key can be used to decrypt the ETSK in order to 
produce the TSK. Once the payment server had produced the TSK, it may decrypt the 
draw request and process the draw request in any suitable fashion with the security card.; . 

35 Once the payment server has received the debit command from the security card, it encrypts 
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: ; . : ' ^^ihe'debit cpmrriandj^tivt^^^^^ the "debit lEP 

u . - : 2 step 8 14 the payment server sends the encrypted debit command 410 to the client 
ternriihal. InJtepJ.l<^^ dec^T^ ft^ it had received 

5 -earlier toni th^^ and processes the debit commsmd in a with 

a stored-vadue cajd^^^^ has;rec^y^^ from 

tlhTe stored- value" message wjth ffie T^^S^^ 

niessage 412 to the piiyment server. In step 820-the:paynient server decrypte the debit 
response message with the a suitable ^'z 

10 fashion with the security CJEurd / - ^ ^ -1. 

Once the payment server has received a "debit result" message from the security card, 
the payment seryer encrypts the "debit result" message with theTSK to form a "debit result 
C" message for the client. The "debit result C" message will be used by the client terminal 
to inform the user of a successful transaction. The payment server also generates its own 
1 5 confirmation message and encrypts die confirmation message with the derived key to form 
a "debit result M" message. The payment server then sends 414 the "debit result C 
message and the "debit result Kf ' message to the client terminal. 

In step 822 the client terminal decrypts and processes the "debit result C" message 
and passes the "debit result M" message 416 on to the merchant server. Because the "debit 
20 result M" message is encrypted with the derived key, the client terminal or other entity is 
not able to tamper with it. In step 824 the merchant server is able to decrypt the "debit 
result M" message because it had originally produced the derived key from the DES key. 
Once the merchant server has determined that a valid "debit result M" message has been 
receivednrconfirms that a valid transaction has taken place and may release merchandise to 
25 the user: 




This security embodiment of FIG. 9 may be used with any of the previously 
described embodiments of the invention. By way of example, this security embodiment 
may be used with the embodiments of Figures 7 and 8 in which there is only one round trip 
between the client terminal and the payment server. In particular, the expected stored-value 
30 card signature received from the security card may be encrypted with the derived key so 

that it unreadable by the client, yet the merchant server will be able to conipare the received 
storcd-value card signature with the expected card signature to validate the transaction. 

A wide variety of terminology may be used to describe the keys described above. 
For example, the keys referred to above as shared DES key, transaction session key (TSK) , 
35 and derived key, may also be referred to as shared key, session C key and session M key . 
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AUTOENTIC^ EMBObiMENf 

no. 16 illustrates an architecture and system 200* for authentication over an internet 
(such as the Internet) using a pseudo stored- value ^plication. This application could 
reside on a stored- Value card along with standard accounts, stored value, or other card 
applications. , The card defines access to the pseudo store^-yalue service jmd ensures that 
^^iheca^l is present amd passes securi^ _ , ^ ^ ^ 

- In one embodiment of the present invention, a consumer inay wish to access any of a 
variety of Web servers in order to redeem frequent flyer miles, award points, etc, that he 
or she has accumiilated. In this embodiment, a consumer has accumulated "points" 
through any of a variety of programs with airlines, restaurants, rental car companies, 
hotels; banks, credit or debit card issuers, telephone or other conuriiinication company, etc. 
The consumer wishes to redeem these points to receive free airline tickets, meals, car 
rental, overnight stays, prizes, awards, discounts, or other "benefits**. By accessing a Web 
server associated with the particular program, the consumer is able to use his or her card in 
any of the embodiments described herein to authenticate the card and to receive these 
benefits from the program. Most often, a card has a card number that is associated with the 
consumer's name in a database on the Web server. This card number is transmitted to the 
Web server as part of the card signature, or in a similar fashion. Thus, an authenticated 
card used in this embodiment to redeem services may be matched to the appropriate 
consumer. , r,-:'_ 

For example, a consumer with 30.000 frequent flyer miles oh one airline may use 
this embodiment of the present invention to access a Web server associated with the airline. 
The consumer is requesting a free round-trip ticket in exchsmge for20,0p0 niiles - : 
present invention then operates to authenticate the consumer's stored- value loyalty, 
application on the card, and delivers a confirmation of authentication message to the Web 
server for the airline. The Web server then deducts 20,000 miles from the consumer's 
account (leaving 10,000 miles) and delivers the free ticket to the consumer. In one specific 
embodiment, the Web server associated with the airline (or the airline itself) keeps track of 
the consumer's account and deducts the mileage. In this instance, an authentication ^ . : 
application is used to validate the presence of the card or to obtain access to the Web server 
site. - . ■ " ■ . '. 

In another specific embodiment, the consumer's card contains a loyalty application'^ 
that stores the consumer's accumulated frequent flyer rnileage; the mileage from the card is ; 
then debited and confirmed to the Web server in a similar fashion as described in various of 
---the embodiments by^ is stored on ani debited from a c^.^^^^^ 
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'-^^^ may be implemented ii^^ • 

elements shown in system 200* having counterparts in system 2(X) are described above and 
have similar functionality. System 200' includes a^we^^ 208 ' that may be any 
suitable computer server capable of presenting aw infprmsdpnXlfwein^ to 
a consumer over an open network such as the Intemet^ Web server 208V ma^ the same 
as merchant server 2(38 of HG. 4 ofsL separate pompjite^ ' is 

implemented in a siiralar fashion as described 

208* includes server module 232' that is preferably implemented in ^ similar fashion as 
merchant module 232. Additionally,; seiy^^ 

present benefits that are available for pardcular consumere/^ F^^ available 
such as airline tickets, prizes, etc., may be presented. - . ">H^ ■ : > :: 



Points (such as frequent flyer miles,'fbr example) that 
achieve benefits may be linked to a particular consumer by an account riuhiber, password, 
or other identifier. The amount of points accumulated for each consumer may be stored on 

15 web server 208' using server module 232\ or may be located in another database of the 
organization providing the benefits. In an alternative embodiment, these points for each 
program that a consumer is enrolled in are stored in a loyalty application on the consumer's 
card. For example, a consumer may have a stored-value card that in addition to storing 
monetary value, also stores a quantity of frequent flyer miles accumulated for a particular 

20 airline (or a number of airlines), points accumulated for using a particular credit card. 

points for hotel staysnat particular hotels, etc. For points stored on the consumer's loyalty 
application card, these points may be verified and debited in much the same way that 
monetary ,value_pn the consumer's card is debited as described herein. 

. - „_One em 

25 on a card^authenticated to redeem points. forjjenefits will iiow be explained. In one 

specific embodiment, a technique similar to that described in the flowchart of FIGS. 1 1 A- 
1 ID for debiting monetary value may be used. Initially, a user (consumer) operating client 
terminal 204 accesses web server 208' over link 234'. views benefits presented for a 
particular program (such as an airline's frequent flyer program), selects benefits from that 

30 program, and requests the transaction to be performed using his or her pseudo stored-value 
application to validate that the card has access to the services. Web server 208' receives 
and processes this request. The above steps may be performed in a similar fashion as steps 
602 and 604. 

Next, similar to step 606, web server 208' sends a page of infonriation to client 
35 terminal 204. When claiming benefits, the total cost field is zero and the currency field is a 
" - - speciflly assigned value^ Keeping total cost field equal to zero causes the system to 

. p^rfpmi authenticato 
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p -wh^seckrd holds the amount of their poiiiti; addidbnal ^Id^ay^ 

to temunal 204 mdicatihe which account to debit anrf hv houi ■«a«l/'r^r»;«fo tk^ t^toi ^^o* > ■ iS^; 



""to termn^ 204 indicating which account to debit and by how m^^ Tlie total cost 

, .^d cmrehcy^fields may be readily adapted for this puipbse^^ r^"-^ 

: a sinwlafffeshion to steps 608-612, re^ message isjmilt^a^^ 

^r^iaiit^^^ ^swrer no^y prpces the draw request in conjunctic^iihie^ 

t^!?^ command and k seoiHt/ daiS 

r As loSi cost is zero/thi; '^dr^ 

: ^ is also zero. In the altemadvc emMiment in which storcd-value caid 5 ^ 

V stores points for a particular program/total cost may be 'a value and a "draw amount* state 

""5"^r. of points to be deducted from card 5. . x 

IJ^-^?^*?^ sehcls the debit command 

anid security c^^d signature client terminal 204 and this infomiation is processed by card 
though a monetary value is not bbing debited, card 5 performs processing such as 
incrementing a counter indicaUng number of transactions and generating a stored-value card 
signature." In the alternative embodiment in which points are stored on card 5. the points 
needed to redeem the benefit chosen by the user from web server 208* may be debited from 
the appropriate account in this step. > 

Steps 620 through 638 are performed in a similar manner as in FIGS. 1 IB and 1 IC, 
except that in this case a monetary transaction is not being verified, but rather card 5 is 
being authenticated to allow the user to complete his access to services or benefits. In step 
626 in particular, the signature of card 5 is verified by security card 2 1 8 . In this 
embodiment, security card 2 1 8 would send an:^*authehtication OK^ iriessage rather than the 
"confirmation" message of step 628. Web server 208' then debits the appropriate number 
of points from the user's account or allows access to a privileged service for the benefit 
requested. In the alternative embodiment in which points are stored on card 5, the 
"authentication OK" message serves nor only as an authentication of card 5,'but also 
confirmation that the correct number of points have been debited from card 5 for the 
appropriate program. Next, similar to step 640, web server 208' releases the benefit 
requested by the user (such as airiine tickets, prizes, discounts, etc.) and the benefit is 
arranged to be delivered to the user. 



It should be appreciated that this technique of redeeming points for benefits may also 
be practiced using any of the alternative embodiments of FIGS. 6, 7 or 8, thereby obtaining 
the advantages associated with those embodirrients. Furthermore, this technique may take 
35 "advantage of the encryption layer embodirnen^^^^^^ Additidn^^^^^^^^ as described 




i 17 illustratesra system 850 loading value onto a stored-value card according 

to one Sribodiirient of a client terminal 204, 
^bank server860 and load:serv^r 862.-rGlieht terminalr204 communicates with card 5 via ' 
yatd reade^^^^ 860 "and load server 862 over any suitable open 

network such^ Suitable embodiments for client terminal, the card reader 

and the stqred-yalue card are described above in the description of a payment technique. : 
PrefeHbiy i ea^^^ 204, bank server 860 and load server 862 implement a 

code mqdule^(si™ operation to the code modules described abpye) in the Java , 
prbgnMtiming langim that provides the functionality described below. For simplicity of 
explanation,^refererice will be made below to "client terminal", "bank server" and "load 
server" ev^n though the resident code is performing the functions. Card issuer 108 has 
been descrilied previously in FIG. 3. Card issuer 108 may be a separate financial 
institution from the bank that includes bank server 860, or card issuer 108 may be the same 
bank that includes bank server 860. 

Bank server 860 is any suitable computer within a bank or other financial institution. 
By way of example, bank server 860 is any suitable personal computer, a workstation or a 
mainframe computer. In one embodiment, bank server 860 runs a "servlet" program (a 
Java applet running on server) for communication with client 204. 

Load server 862 is also any suitable computer and may be located at a third party 
location (such as at a processor) or may be located \yithin the same bank as bank server - 
860. Load server 862 also runs a servlet program for communication with client terminal 
204 and host security module 864. In an alternative embodiment, load server 862 and bank 
server 860 are the same computer which runs two different applications representing the 
functionality of each server. 

Host security module (HSM) 864 is a device known in the. art that may be embodied 
in a hardware "black box" or on any suitable computer. The host security module can be 
implemented in a hardware module outside of load server 862, can be implemented within 
load server 862, can be implemented in software, or can be implemented as a security card 
described above. Host security module 864 contains the encryption keys in hardware used 
for generating signatures (for example SI, S2 and S3) that provide security for the 
transaction. These signatures are used by stored-value caxd 5 and host security module 864. 
to insure that the card is"^not exiDired or coiinteffeit 0^ insure that 
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module 864 is authentic, to insure tharsystem 850 is authentic in general; to provide 
for a valid "trahsacUonliid to pfe^^^^^ keysfor the ' 

generation of a stpred-yaJi^^^^ 864 . : 

could be replaced by a standard tefminal that includiw a security ca^^ such as is shown in ' 
the previous enibodiinen^ Jceys iwduld fe stored in* die ^ 

. security card.-- - t^-rr^^-rli'-i^ 



Briefly, system 850 operates as follows. A- consunSer accesses bank server 860 Via v 
client temiinal 204. Assunung thatqS^^ is not oyeribadied and diat the usier Vacbbutt 
with the b^k has sufficierit funds/the user is able to doWnlqa^ value via bank server 860 
on to his storcd-valuc card 5. Client terminal 204 communicates with load server 862 to 
receive authorization for the load and for higher security. Card 5 may then be used to make 
purchases over the Internet as described earlier in the application or may be us^ for ' 
purchases elsewhere. Once the bank bias downloaded value to card 5, a corresponding 
amount of funds is transferred from the bank to card issuer 108. 

Card issuer 108 places these funds in a holding pool. Once stored- value card 5 is 
used to make a purchase from a merchant, the transaction is captured and settled through a 
settlement service, such as VisaNet The issuer bank decrements the funds pool for the 
amount of the purchase, which is paid to the merchant bank. The merchant bank pays the 
merchant for the transaction. Settlement may occur in any suitable fashion such as is 
known in the art and, in particular, may be implemented as previously described in FIG. 3. 

LOADING DETAILED TRANSACTION FLOW 

One embodiment of a technique by which a stored- value card is loaded over the 
Internet will now be described using the'flowchartlSf nGS^lSA through ISDWith " 
reference to FIG. 1 7. Various of the steps below may occur in a different order; the 
following description is for illustration purposes. Interaction between client terminal 204 
and bank server 860, and between client terminal 204 and load server 862, is preferably 
implemented in a similar fashion as between client terminal 204 and merchaiit seYver 208, 
and between client terminal 204 and payment server 206 as described above, respectively. 
Certain implementation details mentioned above with respect to payment are eiqiially 
applicable to loading a stored-value card. Furthermore, the exemplary flow shown in the 
figures illustrates a successful transaction (although a negative result is also explained ^ 
below in the text). For this reason, a "confirmation" message is referred to, which caii 
more broadly be referred to as a "result" message (to reflect both the possibilities^of success 
and failure of a load). Also, a "load success" message is referred to, which can also be . 
referred to as a "confirmation" niessage, to reiflect its sMiis as either cohfirming a pbsitiw 
load result or a negative load result. 
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~ Initially^ bro^vser of client terrnin^ is^usedTby tiie^^^^ a 

bank server Internet site. In step 87 1 the user selects an option' to load value onto card 5. 
In step 872 the bank server sends a request fp> card information (i current card 

balance and niaximiini card balance); client terminal 204 teads the cunent card balance, 
currency, and other card information via card reader 210 and returns the balance to bank 
server;860r In^step\873 the bank setyer determines the ma^^^ 

thaj^jenough ftinds arc in the user*s account to accommodate a load request j . .. ... 

; - In stjsp §74 the bank server builds an HTML page that includes th^ following client 
applet parameters: the load value; the type of currency being used; the port and IP address 
of the load server; a unique transaction identifier used by bo3i the ibiud server and the bank - 
server to track a transaction; a unique bank identifier assigned to the bank and known to the 
load server; and a session key. Other information may also be included such as the 
currency's exponent, a status URL address of the bank server used for communication 
fronri the client terminal, and other security information to ensure the identity of the bank 
server and the integrity of the message. Other process related information such as software 
release level, encryption methodology and keys may also be conveyed. Once this page has 
been built, the page is sent to the requesting client browser and triggers the activation of the 
client code module (in this example a Java applet) in the client terminal. 

To determine the load value, the bank server requests that the user enter the amount to 
load to the card. Assuming that the user's account is adequate, the bank server requests the 
user's account be debited in step 875 by the load value. Advantageously, the debit request 
from the bank server can use the existing ATM and accounting systems of the bank to debit 
the user's account. From the bank's point of view, value is being transferred from the 
user's account much in the same way that value would be transferred to a user in the form " 
of cash at an ATM. In this situation, though, the value is not being dispensed as cash at an 
ATM, but is being sent over the Internet to a stored-value card. 

In step 876 the client terminal interacts with stored-value card 5 to obtain card 
information in order to build a load request message for later transmission to load server 
862. Once responses from the card are received, the client terminal combines these 
responses into a byte stream suitable for transmission over a network to a load server. 

The client terminal emulates a variety of host security module 864 commands to 
receive responses from these commands from the stored-value card. The stored-value card 
and the security module are physically separated from one another; communication takes 
place over the Internet. In the interest of speed and reliability, it is advantageous to have 
only the traditional authentication, response, and confirmation messages exchanged.-, r- £^^>3 
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. J ; r = - To operate securely and reliably in this environment, in one embodiment of the 
present invention the client terminal emulates a security module and gathers kll the 
; j; Vbspbnses for^ansimssion i one load request message. The load request message7inay 

incliide a variety of information and preferably includes a first card signjiture (termed S I), a 

5 card nunriber, and a load amount. Other information such as tfe s^ 

„ .^g9rithm,Jgan§^^ cOTnter.^urrent card bajance, and bank server time stamp ar^^ 
- preferably provided, j . - - - - ly v 

As all of this information is prepackaged into a single load request message, the 
nuniber of messages exchanged between the stored- value card and the security module over 
10 the Internet is minimized. ^ * , : > - 

Next, in step 877 the client terminal accesses the load server using the IP address 
received from the bank server. In step 878 the client terminal sends the load request ■ 
message to the load server. In step 879 the load server processes the load request in 
conjunction with ah associated host security module 864 as will be explained in greater 

15 detail below with reference to FIG. 18D. After step 879, the load server has received an 
issuer security modqle signature (termed S2) as part of a load command from the security 
module 864. The security module signature is a value that uniquely identifies and validates 
the security module to prove to stored- value card 5 that the incoming load command is a 
valid command from a real security module. Thus, the user of the stored- value card, and 

20 other interested parties are guaranteed that a valid load of the card has occurred. In a 

preferred embodiment of the invention, the security module signature is an encrypted value 
ensuring that no other entity can forge ah identity of a security module. 

- ~ - -In step 880 the load server sends'the load cdnmrnand including with the security 
module signature to the client terminal for the stored-value card to load itself. In step 88 1 . 
25 upon receiving the load command from the load server, the client terminal passes the load 
command to stored-value card 5 which verifies the signature, loads itself by the load value, 
and also generates a load success message, a second stored-value card signature (termed 
S3), and a result code indicating success or failure of the load. In a preferred embodiment 
of the invention, this signature is in encrypted form to prevent tampering. 

30 In step 882, card 5 sends load success message containing the card signature (S3) 

and result code back to client terminal 204. Next, in step 883 client terminal 204 packages 
the load success message along with the card signature and sends them back to load server 
862. In step 884 the load server receives the incoming message. The load server then - 
:processes the message into its components and directs the components to the sepuriQ' ^^^^j^ 
35 module. Next, in step 885 the security module may process this response from the client's 
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-:-"-As the seo^ . ; 7 

value card signature is in f&t a valid one by^comparin^g thVraieiv©d stoi^-V£due caid . 
Signature wim a generated expected value. A successful cdmpansoh indicates that a load • - 
. 5 .success message recei^^ 
"~thaf the storcl-yad^ 

.^.^^t^ij^^hg^u^^ 

,.%T V^.^ is pOSSibl^^^ -r,. 

that the card is invalidra us^ it is ~ 

possible that a user has tampered with- the card to 

occuned, when in fact ajoad^ , . i 

M-oh is slightly differerit;|Fct;ex i; 
card my generate a "negative rcsWftcode^^^ the card has not been ; - 

loaded. Processing of this situation wjould then occW ais foll^^^ 

15 In step 882, card 5 sends ai load message contaim^ 

card signature S3 back to client terminal 204. Client terminal 204 r^ a negative : 

result code, and invokes negative result handling. Client terminal 204 interacts with card 5 
and generates a new load request for a zero value load using "elements from the original 
request, along with a new card signature SI. \ - /^-^ -■ '/■/s^s ■ ■ 

20 The negative result code, along with' the signatures S3 arid new S I rand the zero* - 

value load request are passed to the load server for analysis. The load server determines if 
the transaction counter in the zero value load equals the transaction counter in the previous 
request, along 'with verifying other pertinent information such asjdate^n^ time, card V__ ^ 7 
' "riarhbefraj^d ciirrehcy code and eixLponeiit. If tfie dransactioh'counfers ajre the sarne, then it 

25 is possible that a' valid niegative result has bieen received, but it should be verified because 
the client is not trusted. If the counters are equal, the load server will hold the original S3 
and will generate a new load request to the security module using data element values that 
would have been expected if the original transaction had failed. The new load request 
along with the new S 1 is sent to the security module. The security module then compares 

30 the original S 1 (from the original load request) to the new S 1 . If S 1 is valid, then the 

original negative result is true and the security module generates a signature to confirm to 
the load server that there was no load. The original negative result from the card is then 
released to the security module to complete the original transaction. Processing would 
continue, but a user account would not be debited, and no setderaent need occur because 

35 the card was, in fact, not loaded. If S I is not valid, the negative response is not true and 

then the result ^ode in the original request is changed to reflect a successful load and passed 
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On the other hand, if the transaction counters fi-e^^^ siine, then it is still possible 
that a valid negative result has been re<^ivcd, but itl^i^ul^ be yenfiwi b^i^e the cliefif is 
not trusted. First, the load server decreases the counter in the new load request 

to match that of the original. The request along with the new S I is passed to the security 
module.- The security module calciilates ite own r^ load 
request. If there is no match, it means that the neg^ye result was in error and that the card 
had been loaded.-Processing continues to reflect a loaded cffi-dS% t^^ 
means the negative result was correct and that been increased 

by accident. Ilie user account is not d^^^^ 

Returning now to further processing; in step's 87 the load server logs the response 
received from the security module and li^^ 

the bank identifier, the load vaJue, etc: In generairSny of the ple&bra of iiiformation 
passing through the load server may be added toits^d^tabase. Next, in step 8^^^ the load 
server creates a confirmation message including die u*ansaction identifier and sends this 
message to the client terminal in encrypted form. By sending'this confirmation message in 
encrypted form, the confirmation message may be forwarded to the bank server by way of 
the client terminal without fear of tampering. As the confirmation message is encrypted, it 
would be difficult for the client terminal or another entity to forge a confirmation message 
and trick the bank server into thinking that a valid load had taken place. 

In step 891 the client terminal forwards the confirmation message on to the bank 
server at the URL address previously received from the bank server. The client terminal 
may also post a message to the user informing dial the load has been completed. The client 
terminal also logs confirmation of the load. In step 892 the bank server registers the 
confirmation message. The bank server calls a routine to decrypt the confirmation 
message. If the decrypted confinhation message is acceptable, die bank server determines 
a successful load has occurred. The confirmation message provides assurance to the bank 
that the user's card was in fact loaded with a particular value and prevents fraud. For 
example, a fraudulent user who tries to claim that his bank account was decremented and 
his card not loaded (and should tiius receive more money from the bank) would be 
thwarted because the confirmation message proves that the user's card was in fact loaded. 
Alternatively, the "confirmatiori" iriessage may indicate that a load did not occur, in which 
case the account would not be debited, and no seulcmcnt would occur. 

At this point a successful load of the user's card has occurred (assuming all is well). 
For example, if the user had requested $100. that amount has been decremented from the 
user's account at the bank, and $1 00 has been loaded onto the user's stored-value card. 
Preferably, at this^point the arnoum froj^ the 

bank to the store^-yaJue card 




^^^^^^^^ 
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V transferred so that the card issuer may manage the float on these unspent funds until the > ^ 
. usfer spends &e$lTO50n(M 

meinchant, the caiid fesuef is &ien able to settle the transaction with the merchant using^^^m 
fsuitabie clearing £id^^ad^ system. In alternative embodiment, the bank may iH" 

5 - retain the S lOO^and setde directly widi the merchant In another embodiment, the bank and. 
„ " ^ the card issu^ financial ihstitutiqn, and the $ 100 niay be shifted between pi^ 

Jhe prgmi^^ ..v;^^^:^ ^ . . r^--^.'^^'.-^-^, .^^^^rj^:^: 
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Once the load request message is received by the load server, the load sender parses it into. ^ -■^^'^■■:''W&^i&^'^i^&^rr:' 
the appropriate elements aind passes a request to the security module as will be explained ^ L - ^^^^v^^^^^ 
below. Alternatively, the load server can tniild a netyiwk message aurid sAvitchlhe rcqt^ 
to a remote authentication server. Or, a smart terminal could parse the message and pass ' 
responses to the security module. . - -'-.y^:.—. '-r- ' 



' - : Returning now to a more detailed discussion of step 879, FIG. 1 ID describes a t 
technique for processing a load request message in conjunction with a security mod[uie. 7 



15 In step 895 the load server edits the load request for syntactic correctness and logs the 

request as received. In step 896 the load server constmcts a load request message. In step 
897 the load server passes the load request to the security module to emulate a stored-value 
card interacting with the security module. The lo^ server behaves as if a stored-value card 
were actually interacting in an ATM (for example) through a network to a host with a \ 

20 security module. In this fashion, the load request originating from the client terminal has 
been sent in prepackaged form over the Internet emulating a traditional interaction between 
the stored-value card in an ATM. 



In step 898, the security rriodule verifies the received stored-value card signature (SI) 
to'pfeveht fraud. The security module generates its security module signature (termed S2) 

25 and the load command. The signature S2 will confirm to the client terminal and the stored- 
value card that the host security module is authentic and belongs to the issuer of the stored- 
value card. Additionally. S2 protects against a user trying to perform a fake load, keys out 
of synchronization, a counterfeit card, an expired card, etc. The security module then sends 
the signature and load command to the load server as indicated in step 899. At this point, 

30 step 879 ends and control returns to step 880. 

In another embodiment of the loading technique, a consumer may wish to access any 
of a variety of Web servers in order to load frequent flyer miles, award points, etc., that he 
or she has accumulated. A technique for authentication and redemption of such "points" is 
described above. In the loading embodiment, a consumer has accumulated points through 
35 any of a variety of programs \yith airlines, rcstouran^, rental, c 

credit or debit card issuers, telephone or other communication companies, etc. These 
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points afe'stbred by uie'p^^cfilar airline, etc., that has issued them. TTie consumer wishes 
to load these points onto his or her stored-value card in order to redeem them elsewhere; 
thus receiving airline tickets,' meals', car rental, overnight stays, prizes, awards, discounts, 
or other benefite. By accessing Internet server associated with the particular program, 
the consumer is able to load his or her stored-value card in any of t^^^ . . 

described herein to receive^the benefits of the program, rnuch in the same v/ay that currency 
is ioadeS]'^^""^" ' "'■ ~ ..p^^- . - . - 




COMPUTER SYSTEM EMBODIMENT 



FIG. 19 illustrates a computer system 900 suitable for implementing an embodiment . 

10 of the present invention. Computer system 900 includes any number of pfbceSors 902 _ 

(also referred to as central processing units, or CPUs) that are coupled to stbrage'devices - • 
including primary storage 906 (such as random access nniemory, or RAM) and primary 
storage 904 (such as a read only memory, or ROM), As is well known in the art, primary 
storage 904 acts to transfer data and instructions uni-dircctionally to the CPU and primary 

1 5 storage 906 is used typically to transfer data and instmctions in a bi-directional manner. 
Both of these primary storage devices may include any suitable of the computer-readable 
media described below. A mass storage device 908 is also coupled bi-directionally to CPU 
902 and provides additional data storage capacity and may also include any of the 
computer-readable media described below. Mass storage device 908 may be used to store 

20 programs, data and the like and is typically a secondary storage medium (such as a hard 
disk) that is slower than primary storage. It will be appreciated that the information 
retained within mass storage device 908, may, in appropriatie cases, be incorporated in . 
standard fashion as part of primary storage 906 as virtual nierhoty. A specific mass storage 
device such as a CD-ROM 91 4 passes data unMircctiohally^o t^ CPVi V?^ 'V; - \ • ? *-~ " ' 

25 CPU 902 is also coupled to an interface 910 that includes one pr more input/output - 

devices such as such as video monitors, track balls, mice, keyboards, microphones, touch- 
sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, ; ■ * ' . " 
styluses, voice or handwriting recognizers, biometrics readers, or other coniputers.iCPU^^ ^^^^^ , \ 
902 optionally may be coupled to another computer or tclecomrnunicatiohs net\york using a ; • v v ^ 

30 network connection as shown generally at 912. With such a network c6nnection,-it is ; \ 
contemplated that the CPU might receive information from the net\yprk, brliiight bm^ 
information to the network in the course of performing the above-describeJd Tne&bd;i5teps;#|^^ 
Furthermore, method embodiments of the present invention may execute soie;ly upoK CPU^^ i ^ V 
902 or may execute over a network connection such as the Internet in conjunction with a i^;. ; i a;^ . 

35 remote CPU that shares a portion of the processing.i: ^ „ . :-;^crp^^~iJ^^ 
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CLAIMS 



I . ■ ' * A network payment system for ti^sacting'a skle merchahdise over a network 
using a stored-value card, said network payment system comprising:; 

a router for routing communication between entities attached to said network; 

a merchant server in communication with said network, said merchant server 
having at least a first item of mterchandise for sal^^ J; ^ 

a client terminal in communication with said net>york, said client terminal including 
a card reader for communicating with said stored-value card, an output device for 
reviewing said first item for sale, and an input device for initiating a purchase transaction to 
purchase said first item for sale; and ' V 

a payment server in conununication with said network, said payment server 
including an interface for communicating with a security card and being arranged to receive 
a purchase message including an indication of said purchase transaction and to transmit a 
confirmation message to said merchant server over said network, whereby said merchant 
server is authorized to release said item of merchandise to a user associated with said 
stored-value card. 



2. A network payment system as recited in claim I wherein said network is an internet 
and said merchant server includes a merchant web site for advertising said first item for sale 
over said internet. 



20 



25 



30 



3. — A network payment system as recited in any of claims ror'i Wh^^^ - ^ 
client terminal, said merchant server and said payment server are at a separate location and 

communicate over said network. 

4. A network payment system as recited in any of claims 1-3 wherein said stored- 
value card and said security card are both also suitable for use in an. integrated service 
payment terminal, and said network payment system further comprises: : . 

a clearing and administration system for reconciling a plui^ity of transactions over ^1' 
said network. \ , 

5. A network payment system as recited in any of claims 1-4 wherein said'dienr ^-'V^^- ^^^^ 
terminal further includes a command emulator for emulating security C£u:dcpi^ 
are sent to said stored-value card and for grouping responses to said.T&urij^^X^^ 



commands into a draw request message to be sent to isaid paymenttSv^^ 




- payment server includes a response eniuiatpr for emulating responses from said stored- 

- value card IthatJ^ 
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6/ :'A network payment system as recited in any of claims 1-5 wherein said payment :f . 
server includes a comparator for comparing a stor^^^ 

said stored-value card with an expected signature received from said security card to - : 
confirm a transaction, whereby the message traffic between said payment server and said ; 

'■"''seciraty''^ is''reduc»il"'^''_' " >— - -• ^ - 

7 A network payment system as recited in any of claims" I r5 wherein said client "v 
terminal includes a comparator for comparing a stored-yalued card signature received from ^-i'. 
said stored- value caird with ari'expected signature from smd se^^^ received via said r 

payment server to confirm a transaction, whereby message traffic between said payment 

' server and sadd client tenriinal, and between said payment server and said security card is 

V reduced.- / - . 



S, A network payment system as recited in any of ciainis 1 -5 y/herein said merchant 
1 5 server includes a comparator for comparing a stored- valued card signature received from 
said stored-value card with an expected signature from said security card received via said 
payment server, whereby a transaction is confirmed and whereby message traffic from said 
payment server, and between said payment server and said security card is reduced. 

9 . A compuler-irnplemented method of selling merchandise oyer a network using a 
20 merchant server, said merchandise for purchase by a user with a stored-value card, said 
method comprising: 

establishing conmiunication between smd mercharil seiner 
network; 



25 



receiving a request from said client to purchase an item available from said merchant 



server; 



transmitting to said client a purchase amount of said item so that said client may 
debit a stored-value card associated with said client by said amount; 



transmitting said amount, a transaction identifier and a merchant identifier to a 
payment server connected to said network, said transaction identifier uniquely identifying 
30 the purchase of said item and said merchant identifier uniquely identifying said merchant 
server to said payment server; and 

a confirmation step for performing the function of confirming said purchase of said V , - ; 
item to said merchant server, whereby said merchant server is informed that said sale of -r . : 







W098/49658 



PCT/US98/08806 



said item is a success and said merchant server may release said item to said user associated 
with said stored-value card. 



10 
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10. A method as recited in clmm 9 wherein said netwoiic is an internet, wherein said 
merchant seiVer includes a meichanf web site^f^^^ over said 
internet, wherein said client arid said jSieich^^^^ server are at separate lociations and said 
recited steps of said methodloccu^^^^^ ' ^ ^- t- -^t.-^ ~ - 

11, A meSod as recited in a^^^ 

transniitting a key to said client for encrypting a draw request message to be sent to 
said payment server from said client terminal; ■ 

providing said key to decrypt said encrypted draw request message to said payment 
server without sending said key in the clear to said payment server; and 



receiving an encrypted transaction confirmation message from said payment server 
that is encrypted by a key shared between said merchant server and said payment server. 

12. A method as recited in any of claims 9- 1 1 wherein said step of transmitting said 
purchase amount and said confirming step are routed through said client to provide 
communication between said merchant server and said payment server, whereby the 
numberof communication links is reduced. 



13. A computer-implemented method of transacting a sale of merchandise over a 
network using a client terminal in association with a stored-value card, said method 
-20 J . comprising: — -^ -y. - — ^ - - " - - 

transmitting over said network a request from said client terminal to purchase an 
item available from said merchant server, 

receiving from said merchant server an amount of a cost of said item; 

sending a draw request message to a payment server connected to said network so 
25 that said draw request may be processed by a security card associated with said payment 
server; 

receiving a debit command from said payment server; 

debiting said stored-value card associated with said client terminal by said amount; 



and. 
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. : sending confirmation infomation to sl^^^ 

server is informed that said sale of said item is a success'aiid said merchant server may 
release said item to a user asspciat^ 

14. A method as recited in claim 13 wherein said net^ 
5 merchant server includes a merchant web site for ady 

: internet, wherein said client terminal and said merchanrse^^^ at separate locations and 
V { said recited steps of said method occur over said internet/ 

15. A method as recited in any of claims 1 3 or 14 further comprising: 

eniulating security card commands that are sent to said stored-value card associated 
- 10 with said client teimn^ - 

grouping responses to said security card commands into said draw request message 
so that said responses may be sent as a group to said payment server to reduce network 
traffic between said payment server and said client terminal. 

16. A method as recited in any of claims 13-15 wherein said confirmation information 
15 includes an encrypted confirmation message unreadable by said client terminal, said method - 

further comprising: 

receiving said encrypted confirmation message from said payment server. 

17. A method as recited in any of claims 13-15 wherein said confirmation information 
includes a confirmation message, said method further comprising: 

„v .^r 20 1 „ ; receiving an expected stored-value card signature from said security card via said - 
paynjent server; 

receiving an actual stored-value card signature from said stored-value card; 

comparing said actual stored-valued card signature received from said stored-value 
card with said expected stored-value card signature from said security card; and 

25 generating said confirmation message for transmission to said merchant server, 

whereby message traffic between said payment server and said client terminal, and between 
said payment server and said security card is reduced. 

18. A method as recited in any of claims 13-15 further comprising: 

r receiving an encrypted stored-value card signature from said security card via said ; 
30 payrneni server that is unreadable by said client terminal; 
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, receiving a raw stored-value card signature from said stored-value card; and . 

V . - V transmitting to said merchant server as said confirmation information said encrypted 
stored^ value card signature and said raw stored-value card signature for comparison by said 
nierchant server, whereby message traffic between said payment server and said client = ^ 

5 teiminal, and between said payment server and sa^^ 

19r " A methbdas^ 

receiving a security card signature for validating said security card to said stored- 
value card, said security card signature being received in the same message from said 
payment server as said debit conrimand; iamd; 

10 receiving an expected stored-value card signature for comparison to an actual 

stored-value card signature, said expected stored-value card signature being received in the 
same message from said payment server as said debit command, whereby message traffic " 
between said payment server and said client terminal, and between said payment server and 
said security card is reduced. 

15 20. A computer-implemented method of managing a transaction between a client 

terminal and a merchant server connected over a network, said transaction being managed 
by a payment server also connected to said network, said method comprising: 

receiving a draw request over said network, said draw request including an amount 
indicative of a cost of an item available from said merchant server, a transaction identifier 
20 uniquely identifying the purchase of said item, and a merchant identifier uniquely 
identifying said merchanTserver to ^^^^ 

sending said draw request to a security card associated with said payment server so 
that said draw request may be processed by said security card; 

receiving a debit command from said security card; 

25 sending said debit command from said payment server destined to said client 

terminal over said network so that a stored-value card associated with said client terminal 
may be debited by said amount; and ; \ , 

a confirmation step for performing the function of confirming said purchase of said 
item to said merchant server, whereby said merchant server is informed that said jpurchase 
30 of S£dd item is a success and said merchant server mav release said item -to a user associ^ 
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" " " 2 ir?^^ iri clmm 20 wherciil said network is Sh intemW/ wherein 

merchant server includes a merchant web site for advertising said item over said internet^ 
wherein said client terminal and said merchant server are at separate locations and said ^A^I^^^W 
\ raited ^s;pf said meth^^ " ' \: : ^..r,''^-' 

. 5 _ ^,22.-^^A method as recited in any of claims 20 or 21 wherein sjaid stored- value carded ^^^^^^^^^^^^ 
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\ r^:? sending tninsaction information regarding said sale < 
administration system for reconciling said sale. 

;i3^ ; ; "^A m^^ recited in any of claims 20-22 coir^in^; _ 

■ . receiving as part of said draw request responses froni said stored- value card to ^ ^ 
security card commands that have been emulated by said client terniinal; a^ ;? 

emulating said stored-value card responses in an interaction with said security card 
to receive responses from said security card, whereby network traffic between said 
payment server and said client terminal is reduced, : i\ ■ ^ 



24. A method as recited in any of claims 20-23 wherein said confirmation step includes 
the sub-steps of: 

receiving a signature from said stored-value card associated with said client 
terminal; 



20 - _ jending said. signature to said, secimtyj;^d^^^ 

receiving a transaction OK message from said security card; and 
sending a confirmation message destined for said merchant server. 



25 



25. A method as recited in any of claims 20-23 wherein said confirmation step includes 
the sub-steps of: 



receiving a signature from said stored-value card associated with said client 



terminal; 



comparing said received signature with an expected signature received from said 
security card; and 




sending a confirmation message "destined for Hid'merchaiit ser^^ whereby 
message traffic between said security card and said paynrient server is reduced. 



26. A method as recited in any of claimis 20-23 wherein said confirmation step includes 
the sub-steps of: . - 



and 



receiving an expect«i sigiij^^^ security card; 



sending said expected signature to said client tenhinai so that said client terminal 
may compare said expected signature to «ui 2u:tuiQ sigha^^ said stored-value card, 
whereby message traffic between said security card and said payment server, and between 
said client terminal and said payment server is reduced. ' 

27. A method as recited in any of claims 20-23 wherein said confirmation step includes 
the sub-steps of: 

receiving an expected signature of said stored-value card from said security card; 
encrypting said expected signature so as to be unreadable by said client terminal; 

and 

sending said encrypted expected sighiature to said client terminal for resending to 
said merchant server so that said merchant server may compare said expected signature to 
an actual signature of said stored-value card, whereby message traffic between said security 
card and said payment server, and between said client terminal and said payment server is 
reduced. „ . ^ _ - „ 

28. A method as recited in any of claims 20-27 further comprising: 

sending a security card signature for validating said security card, said security card 
signature being sent in the same message destined to said client terminal as said debit 
command; and 

sending an expected stored-value card signature for comparison to an actual stored- 
value card signature, said expected stored-value card signature being sent in the same 
message destined to said client terminal as said debit command, whereby message traffic 
between said payment server and said client terminal, and between said payment server and 
said security card is reduced. 



m 
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. , . 29?^^A"computer-implefnerited m bf interacting with a stpred-value cara by'a blieht 
: % Je to facilitate the sa^^^ of an item of merchandise over a network, said method - - 

• ■~-.^;^:'^^'tS'?'^t-r>^ . " ' . . ' \ 

7 receiving a purchase; amount for said item of merchandise from a merchant server 

7 ' 5 connected to said network; ^ - >^ - - - - - - 

-.1; - .-emulating a plurality of security card commands that are sent to said stoned-value 

^ card associated with said client terminal ; ' ; ^ " r^j - ^ - ' r " ~ 

receiving a plurality of resp)onses to said security card commands from said stored- 
valuecard; . 

10 grouping said responses to said security card commands from said stored- value 

card together with said purchase amount to form a draw request message; and 

sending said draw request message to a payment server over said network so that 
said draw request may be processed by a security card associated with said payment server 
to facilitate said sale of merchandise over said network, whereby network traffic between 
15 said payment server and said client temndnal is reduced. 




7U)^^ 
^7«^^ 



30. A method as recited in claim 29 wherein said network is an internet, wherein said 
merchant server includes a merchant web site for advertising said rnerchandise over said 
internet, wherein said client terminal and said merchant server are at separate locations and 
said recited steps of said method occur over said internet. 



20 31. A method as recited in any of claims 29 or 30 further comprising: 



receiving a debit command from said payment server destined for said stored-value 
card; said debit command being generated by said security card; 



receiving a security card signature, for validating said security card to said stored- 
value card, said security card signature being received in the same message from said 
25 payment server as said debit command; and 

receiving an expjccted stored-value card signature for comparison to an actual 
stored-value card signature, said expected stored-value card signature being received in the 
same message from said payment server as said debit command, whereby message traffic 
between said payment server and said client terminal, and between said payment server and 
30 said security card is reduced. 



51 
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32. A computer-ifnplemented method of interacting with a security card to facilitate the 
sale of merchandise over a network, said method compnsmg: 

receiving a draw request message from a client terminal over said network, said 
draw request mesisage including a plurality of from a stored-value card generated 

in response to emuladonjof security card commands, and also including a purchase amount 
for said nierchan'disei whereby nehvork traffic ^fe^ said payment server and said client- 
teririinal_is rcduowi; J^^^ 

emulating said stoi^-value card responses in an interaction with said security card 
associated with said payment server; 

receiving a plurality of security card responses from said security card in response 
to said emulation; and 

sending a debit command destined to said client terminal over said network so that 
said debit conunand may be processed by said stored-value card associated with said client 
terminal to facilitate said sale of merchandise. 




15 33. A method as recited in claim 32 wherein said network is an internet to which is 
connected a merchant server having a merchant web site for advertising said merchandise 
over said internet, wherein said client terminal and said merchant server are at separate 
locations and said recited steps of said method occur over said internet. 

34. A method as recited in any of claims 32 or 33 further comprising: 

_ ^ „ ^ confirmation jitep for performing the function of confirming said sale of . 

merchandise to said merchant server, whereby said merchant server is informed that said 
sale of said item is a success and said merchant server may release said merchandise to a 
user associated with said stored-value card. 



35. A method as recited in any of claims 32-34 further comprising: 

25 sending a security card signature for validating said security card, said security card 

signature being sent in the same message destined to said client terminal as said debit 
command; and 

sending an expected stored-value card signature for comparison to an actual stored- 
value card signature, said expected stored-value card signature being sent in the same 
30 message destined to said client terminal as said debit cpmmand, whereby message traffic 

between said payment server and said client terminal, and between said payrheht server and^^^ 
j. \ said security card is r^uced. - 



i • 3 : ■ 
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■ ' bank seiy^ said network, said bank server arranged to 

5 - debit a user acioun^^^^ > ' 

: -_:_ l:ca client teminal Jn/conimunication wit^ said network, said client terminal including 
a card readerfor cofim a stored-value card and ism input device for indicating 

aValue t6;debiteUfr6tf 

> a load server in (pornmunication with said network, said load server including an 
10 . interface for commu^^^^ being arranged to receive a load 

request including a stored-yalue card .signature and being further arranged to transmit a 
confirmation message to said ijfiik^seiA^eir over said nistwork, thereby assuring that said 
stored-value card has been loaded by said indicated value. 

37. A loading system as recited in claim 36 wherein said network is an internet and said 
1 5 bank server includes a bank web site for accepting a load request. 

38. A loading system as recited in any of claims 36 or 37 wherein said client terminal 
and said bank server are at separate locations and communicate over said internet 

39. A loading system as recited in any of claims 36-38 further comprising: 

a clearing and administration system for reconciling said debit of said user account 

20 , ._\yjth a purchase using said stor<^^ ^ _ y:_;_ :r:--^. 

40. A loading system as recited in any of claims 36-39 wherein said client terminal 
further includes a command emulator for emulating security module commands that are sent 
to said stored-value card and for grouping responses to said security module commands 
into a load request message to be sent to said load server, and wherein said load server 

25 includes a response emulator for emulating responses from said stored-value card that are 
sent to said security module. 

41. A loading system as recited in any of claims 36-40 wherein said security module 
includes a comparator for comparing a stored- valued card signature received from said 
stored-value card with an expected signature to confirm a transaction. 

30 42. A cqniputer-implemented method of loading a stored-value card oyer a network 
comprising: ' 



1 0 recited steps of said method occur, wherein said bahk server includes a bank web site for 
accepting a load request, and wherein said client and said bank server are at separate 
locations. 

44. A method as recited in any of claims 42 or 43 wherein said confirmation step 
includes receiving a confirmation message that originates from one of said load server and a 

1 5 security module associated with said load server. 

45 . A method as recited in any of claims 42-44 further comprising: 

transmitting a first key to said client for encrypting a load request to be sent to said 
load server; 

.. J providing said firist key to decrypt said encryipted load request to said load server 
20 without sending said first key in the clear to said load server, and 

receiving an encrypted confirmation message from said load server that is encrypted 
by a second key shared between said bank server and said load server. 

46. A method as recited in any of claims 42-45 further comprising: 

debiting a user account by said load value; and 

25 sending transaction information including said load value to a stored-value card 

issuer for later settlement. 



47. 



A computer-implemented method of loading a stored-value card over a network 
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- -3 -v-: network from a client terminal to a barik'ser^^^ 

a stored;value!ca^ . ^ v^^- k ^ ^ 

^: ' from said bank server a verified load value; r "k 

■ : sending a load request to a load server connected to said network; 7 

icceiying a load command from said load server, : . . 

loading S2ud stored-^^^ . , . : . - - 

.sending confirmation information to said bank server, whereby said bank server is 
assured that said loading is a success. . . ^ v 

48. A method as recited in claim 47 wherein said network is an internet over which said 
recited steps of said method occur, wherein said bank iserver includes a bank web site for 
accepting a load request, and wherein said client terminal and said bank server are at 
separate locations. 

49. A method as recited in any of claims 47 or 48 further comprising: 

emulating security module commands that ate sent to said stored-value card 
associated with said client terminal; and 



^^^^^^^^ 



grouping responses to said security module commands into said load request so that 
said responses may be sent as a group to said load server to reduce network traffic between 
said load server and said client terminal, 

50. A Jiiethod as recited in any of cladms 47-49 .wherciri"said confirm 

20 includes an encrypted confirmation message unreadable by said client terminal, said method 
further comprising: 

receiving said encrypted confirmation message from said load server. 

51. A computer-implemented method of managing a stored-value card load transaction 
between a client terminal and a bank server connected over a network, said method 

25 comprising: 

receiving by a load server over said network a load request, said load request 
including a stored-value card signature; 
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sending said stored-value car^^ associated with said 

load server so that said stored-value card signature niay be validated by said security 
rnodule;, -, / . ■\^:vJ^'l--'r-..:-:.- 

receiving a load command from said ^cu^ty ; ]' 7 

: ^.^?L^i"S said Ipad^conmianc^^ client terminal so. 

that a stored-value card associated with said client terminal may be loaded by a load value; 

a confirmation step for performing the function of confirming the loading of said 
stored-value card, whereby a bank server is informed that the loading is a success. 

52. A method as recited in claim 5 1 wherein said network is an internet over which said 
recited steps of said method occur, wherein said bank server includes a bank web site for 
accepting a load request, and wherein said client terminal and said bank server are at 
separate locations. 




53. A method as recited in any of claimis 5 1 or 52 further comprising: 

1 5 receiving as part of said load request responses from said stored-value card to 

security module commands that have been emulated by said client terminal; and 

emulating said stored-value card responses in an interaction with said security 
module to receive responses from said security module, whereby network traffic between 
said load server and said client terminal is reduced. 



20 54. A method as recited in any of claims 51-53 wherein said confirmation step includes 
the sub-steps of: 



comparing said received stored-value card signature with an expected signature; and 

sending a confirmation message destined for said bank server, whereby said bank 
server is assured that said stored-value card has been loaded. 



25 55. A computer-implemented method of interacting with a stored-value card by a client 
terminal to facilitate die loading of said stored-value card over a network, said method 
comprising: 



30 



receiving a load value from a bank server connected to said network; . ^ : 

emulating a plurality of security module commands that are sent to said storeid^djue ^^.^^^^^^^"'^^ 
card associated with s^d client terminal; , ^ J-^ 
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. 7" receiving a plurality of rcsponses'to smd se^^^ from said ! v 

stored- value card; v : / : - 

grouping said responses to said security module commands from said stored- value 
card to form a load request; and _ - 

5 sending said load requMttp a load Sicrwr over 

request mj^ be^processed by a seCunty module a^^ with said load server to facilitate ^^5^^~r^.: 
, J the loading of said^fed-y^^ caSd oyersaici hetworic/v/hgi^^ traffic ixsts^^een ■. ^iS^ 

: said load seiyer imd said ' " ^ ^ ^ > 

56 . ^ A method as recited i n claim 23 wherein said network is an internet over which said - ^--^'W^^H^^^^'^ 
recited steps of said method <^ wherein said Isank server includes a bank web siteYor , 1 
acceptinjg a load request, and wherein said client terminal and said bank server are at'^ ; r ^ ^ 
separate locations. \.. _ . ^ : > , , > 

57. A iriethod as recited in any of clainis 55 or 56 further comprising: r 

receiving an encrypted confirmation message from said load server that is 
unreadable by said client terminal; and 

sending said encrypted confirmation message to said bank server, whereby said V 
bank server is assured that said stored- value card has been loaded. , 17 

58. A computer-implemented method of interacting with a security module by a load 7v 
server to facilitate the loading of a stored-value card over a network, said method . 
comprising: ■ -i ^ . - ^ 
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receiving a load request from a client terminal over a network, said load request 
including a plurality of responses from a stored-value card generated in response to 
emulation of security module commands, whereby network traffic between said load server 
and said client terminal is reduced; , - 

emulating said stored-value card responses in an interaction with said security 
module associated with said load server; 

receiving a plurality of security module responses from said security module in 
response to said emulation; and 

sending a load conrunand destined to said client terminal over said network to 
facilitate loading of said stored-value card. „ v7 l^. . - - 




-PCT7US98/08806fS 



are 



" 59.^3?^;-A*meth6d as recited in claim 58 wherein said network is an internet over which said 
recited steps of said method occur, and wherein said client terminal and said load server 
at ^parate loc^ons. ^ 

60. ' j JjA meihod as recited in any of claims 58 or 59 further comprising: 




5„ .^^-.^v0^ for performing the function of confirming loading of said - _r^.; 

stored-yalue card, whereby said bank server is assured that said stored- value card has been 

loaded3% ^ ' ' ' 
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USER ACQUIRES AND ADDS VALUE TO A STORED-VALUE CARD 
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USER INSERTS CARD IN CARD READER AT CLIENT TERMINAL 
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USER SELECTS GOODS AND/OR SERVICES FOR PURCHASE FROM MERCHANT WEB SITE 
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INTERNET PAYMENT ARCHITECTURE AND SYSTEM PROCESSES ORDER 
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MERCHANT RECEIVES PAYMENT TO BANK ACCOUNT BY WAY OF 
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MERCHANT SERVER SENDS PAGE OF INFORMATION TO CLIENT TERMINAL 
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CLIENT SENDS •DEBIT RESPONSE' MESSAGE 
ENCRYPTED WITH TSK TO PAYMENT SERVER 
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